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Preface 



This volume comprises the papers presented at the Fourth International Andrei 
Ershov Memorial Conference “Perspectives of System Informatics”, Akademgo- 
rodok (Novosibirsk, Russia), July 2-6, 2001. The main goal of the conference 
was to give an overview of research directions decisive for the growth of major 
areas of research activities in system informatics. 

The conference was held to honor the 70th anniversary of the late Acade- 
mician Andrei Ershov (1931-1988) and his outstanding contributions towards 
advancing informatics. It was the fourth conference in the line. The First Inter- 
national Conference “Perspectives of System Informatics” was held in Novosi- 
birsk, Akademgorodok, May 27-30, 1991, the second one on June 25-28, 1996, 
the third one on July 6-9, 1999. The three conferences gathered a wide spectrum 
of specialists and were undoubtedly very successful. 

The fourth conference included many subjects of the previous ones, such as 
theoretical computer science, programming methodology, and new information 
technologies, which are the most important components of system informatics. 
The style of the three previous conferences was preserved to a certain extent: a 
number of invited papers were presented in addition to contributed regular and 
short papers. 

This time 73 papers were submitted to the conference by researchers from 19 
countries. Each paper was reviewed by three experts, at least two of them from 
the same discipline as the authors or a closely related one. The reviewers gene- 
rally provided high quality assessment of the papers and often gave extensive 
comments to the authors for the possible improvement of the presentation. As 
a result, the program committee selected 26 high quality papers as regular talks 
and 22 papers as short talks. Some hot topics in System Informatics were co- 
vered by four invited talks given by prominent computer scientists from different 
countries. 

To celebrate the 70th anniversary of the late Academician A. P. Ershov, a spe- 
cial memorial session was organized. It included two invited talks and a number 
of short informal communications. The invited talks were given by two prominent 
Russian computer scientists who worked either side by side with A. P. Ershov or 
in a closely related area. 

Andrei P. Ershov was a man for all seasons. He commanded universal respect 
and received affection all over the world. His view of programming was both a 
human one and a scientific one. He created at Akademogorodok a unique group 
of scientists - some now in far away regions of the world: a good example of 
“technology transfer” , although perhaps not one that too many people in Russia 
are happy about. 

Many of his disciples and colleagues continue to work in the directions initia- 
ted or stimulated by him, at the A. P. Ershov Institute of Informatics Systems, 
which is the main organizer of the conference. 
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A.P. Ershov — A Pioneer and a Leader of 
National Programming 



Igor V. Pottosin 



A. P. Ershov Institute of Informatics Systems 
Russian Academy of Sciences, Siberian Branch 
6, Acad. Lavrentjev ave., 630090, Novosibirsk, Russia 
ivpOiis .nsk. su 



April 19, 2001, seventy years had passed since the birth of Andrei Petrovich 
Ershov. He was a pioneer of programming in this country, and one of its leaders; a 
scientist with considerable and decisive influence on the development of national 
programming. I have already tried to overview A. P. Ershov’s scientific findings 
in a paper recently published in a collection of his selected works; this memorial 
report is primarily intended to tell the story of A. P. Ershov as a pioneer of 
programming and as its leader for many years. 

A. P. Ershov was becoming a scientist just at the time when programming 
was becoming a science. This is unique to his scientific career, so different from 
that of his contemporaries who had previously worked in other domains. Not 
only did he have to be a researcher but also a propagandist, a defender, and 
an organizer, as this newly created discipline required him to be. His scientific 
findings and his organizational activities are important both in themselves and 
for their role in the auto-identification of the new scientific trend and in setting 
up the framework for its internal research. 

1950 was the starting point for programming in this country, when a model of 
MESM was created, the first computer in the USSR and in continental Europe. 
Ershov had devoted his life to programming two years later, choosing his major 
in computational mathematics at the Faculty of Mathematics and Mechanics at 
Moscow State University. He was in the group of graduates who were the first 
to be certified as programming specialists in the USSR. Among his fellow grad- 
uates were E. Z. L’ubimsky, V. S. Shtarkman, I. B. Zadyhaylo, V. V. Lucikovich, 
O.S. Kulagina, N.N. Rikko, and others. 

It is interesting to look at the origins of the first generation of programmers. 
In no case they dreamed of devoting their lives to programming from the school 
bench. As a rule, they came from related branches of science: mathematics, me- 
chanics, physics, engineering; and some teachers of mathematics were also among 
them. Ershov and his colleagues were distinguished from others as an elite, since 
only they had a basic education in this new held. Actually, Ershov had dreamed 
of becoming a physicist and only circumstances urged him to enter the Faculty of 
Mathematics and Mechanics. Ye. A. Zhogolev, who has contributed to the orien- 
tation of Ershov towards programming, remembers that it was Ershov’s interest 
in the physical principles of computers that has led him to study computational 
mathematics — the only course where these principles were being studied. 
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Initially this new discipline could not be regarded as a discipline in itself 
and had to be called by another name. Note: not under an alien name, but 
under another name. All those who moved to programming were given the label 
“mathematicians” independently of their original specialty. It is worth noting 
that the “computing world” of that time roughly consisted of two camps. The 
people in one camp were labeled “engineers” ; those in the other camp were called 
“mathematicians” and they were in fact, programmers, the people who produced 
software. 

To be incorporated into mathematics was, on the one hand, rather natural. 
It was necessary to develop under some “umbrella” or other, and the umbrella 
of mathematics was the most appropriate one: the strictness and accuracy of 
decisions and the purely intellectual nature of the resulting product character- 
ize both mathematics and programming. But on the other hand, several facets 
of programming (the importance of pragmatics, impossibility — to this point 
of time — to deduce everything from proofs alone) distinguish it from mathe- 
matics and made it — for some mathematical Puritans — a “dirty” branch of 
mathematics. I remember hearing M.I. Kargapolov say (rather typically): “We 
always had mathematics with theorems, and now we have a new mathematics — 
without theorems.” Many mathematicians, especially those working in the field 
of computational mathematics, thought that the unique role of programmers 
was to serve demands imposed by computational tasks and that there were not 
and could not be any internal problems relating to the programming itself. 

There was only one way to react to such views: to build a foundation for 
the new scientific discipline, to develop its models and methods which could 
testify to the existence of essential problems inherent in programming and thus 
to promote its auto-identification as a distinct scientific domain. 

Being one of the pioneers of programming, Ershov was well acquainted with 
the problems involved in creating a new discipline. He had finished his candi- 
date thesis dedicated to one model of programs (operator algorithms) in 1959; 
it was not until 1962 that he could support it. “Pure” mathematicians could 
not understand its importance: namely, that the model presented adequately 
reflected essential properties of real programs. Ershov was also permanently op- 
posed while working on his famous Alpha-project. As many people claimed, a 
team of experienced programmers would be better off writing useful applied pro- 
grams than a useless compiler which in no case would achieve its declared goal 
— translating programs written in an Algol-like language into programs whose 
quality would be comparable with hand- written programs. 

There were two possible reactions to these external difficulties in the life of 
programming. One could “give up”: either investigate the purely mathematical 
problems of programming (they are numerous, thank goodness) or perform com- 
putational tasks without even trying to see programming as a domain in its own 
right. Conversely, one could break ties with mathematics and develop program- 
ming systems without any attempt to employ precise or formal methods. The 
wisdom of Ershov prevented him from taking either of these paths. He simulta- 
neously and in an interconnected way developed both the conceptual foundation 
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of programming and precise mathematical models that formalize as far as pos- 
sible corresponding concepts. Ershov’s school of programming in Novosibirsk is 
based upon this very combination. 

Ershov’s first scientific results (and this was also the case for most program- 
ming pioneers) were connected with computational tasks. His first paper was 
the article “One method of the inversion of matrices” (“Doklady Akademii Nauk 
SSSR”, 1955), but Ershov would not have become a programmer, had he not 
written a standard program for the BESM computer implementing this new 
method. In fact, the choice of this topic was motivated by Ershov’s primary 
mathematical interest: prior to choosing computational mathematics as his ma- 
jor he intended to specialize in algebra. But being challenged by the internal 
problems of programming, Ershov, like many other pioneers, moved to com- 
pletely new, unexplored areas: programming languages and systems were the 
first among them. Ershov was not the first in that field, but he was one of the 
early groundbreakers. He was one of the developers of the Programming Pro- 
gram for the BESM computer which was one of the first domestic compilers. 
His brilliant ideas mainly contributed to the basis for language concepts and 
compilation methods. Ershov was the first to suggest (at least in this country) 
such a language construct as a loop and such a method as a hash function. In 
1958 he published a well-known book on compiling, the first in the world, later 
translated into English (1959) and also into Chinese. 

Beginning with his very first works, Ershov was recognized as a leader in 
the field of programming languages and systems. The ideas suggested by Ershov 
and the experience gained when carrying out his projects — the optimizing 
compiler Alpha, the cross-compiler Algibr, the Alpha-6 compiler for the Besm-6 
computer, and the multi-language compiling system BETA — have contributed 
to the modern fundamentals of compilation. Memory optimization techniques, 
the notion of internal language as a semantic representation of programs for 
their optimization or cross-compilation and unified compilation scheme should 
be mentioned as Ershov’s personal contribution. 

Ershov has also greatly contributed to the development of programming lan- 
guages that succeeded Algol-60: the Alpha-language, an extension of Algol-60, 
already contained some features appropriate to modern languages, such as multi- 
dimensional values, a variety of loop constructs, initial values and so on. His 
Sigma language is an example of a language kernel extensible with the mecha- 
nism of substitution. 

Ershov’s results on specializing programs by means of mixed computation are 
widely recognized. Ershov had predecessors in this field (Futamura, Turchin) but 
it was he who cristallized the principle of mixed computation which later gave 
an impetus for many theoretical and practical works on mixed computation and 
partial evaluation. His disciples have produced works on practical and highly 
efficient mixed computation. His ideas incited some other approaches to special- 
izing programs, such as concretization. Ershov has also formulated the notion 
of a transformational machine as an approach to constructing reliable and high- 
quality software. These ideas form the basis of a new trend of programming. 
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namely transformational programming, which looks promising, though as yet 
has not been practically applied on a wider scale. 

A special place in Ershov’s works is occupied by the AIST project. I think 
that the significance and value of this highly innovatory project have been under- 
estimated. In this project Ershov headed the construction of the entire comput- 
ing system, both its architecture and software. The initial stage of this project, 
AIST-0, has been one of the first national multi-processor systems with a rich 
software providing different access modes from batch to time-sharing. 

The AIST software was being developed practically in parallel with other 
projects, both in the USSR and abroad, on constructing powerful operating 
systems, prototypes of modern OS (Multics, OS IPM and others), and it was re- 
markable and original enough in comparison with these systems. As to the AIST 
architecture, it was the first complex architectural project in Novosibirsk, fol- 
lowed later by another original projects carried out in the Institute of Mathemat- 
ics and in the Computing Center of the Siberian Branch of the USSR Academy 
of Sciences. The software model had three levels: the kernel of the OS, special- 
ized interactive systems and application software. The project was interrupted 
and next stages were not realized because of approval of a possibly erroneous 
national program, about which Edsger Dijkstra once said: ’’The greatest success 
of the USA during the cold war was the fact that the USSR accepted the IBM 
architecture.” 

The first generation of programmers had the honour of building a concep- 
tual framework, a fundamental basis of the new scientific discipline. They were 
like newcomers ’’with the world so new-and-all” (R. Kipling) and they came up 
with ideas and developed methods by evaluating their own experience. Ershov 
with his mathematical training and his experience in heading several essentially 
new projects (some of which have been just mentioned) has done much towards 
laying foundations of the new discipline. I want to mention one important de- 
tail: he paid due attention to the work on terminology. He himself introduced 
several fundamental terms of the Russian professional language, such as “infor- 
matics”, “programmnoe obespechenie” (literally “programming provision”) for 
“software”, “technology of programming” for “software engineering”, etc. It was 
not only the case of inventing new names. Substantial conceptual and method- 
ological work backed these names. 

Let us return to the term “informatics”. As said above, Ershov, like all of 
us, considered himself for a long time as a person working in a peculiar, but still 
mathematical, field and did not fully realize the uniqueness of his job. It was 
not easy to leave the habitual umbrella but when specific scientific luggage had 
been accumulated, recognition of this specificity became inevitable. As soon as 
Ershov realized that a new discipline had come in existence, he made a decisive 
step, proposed the new term “informatics”, and published the paper “On the 
Subject of Informatics” where he outlined the subject and the meaning of the new 
science. Ershov gave to the term “informatics” a wider interpretation than that 
of its traditional English equivalent “Computer Science”. Namely, he understood 
it as a fundamental natural science studying processes of information transfer 
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and processing. As to “computer science” itself, it is referred to as the “working” 
up-to-date content of informatics. 

No less important was Ershov’s coining of the phrase “technology of program- 
ming” (“software engineering”). The first generation of programmers considered 
the process of software construction as a highly intellectual work akin to scientific 
research. And they were right, to some degree and in the initial stages. Ershov 
was the first (at least in this country) who saw the other side of programming, 
the industrial rather than the scientific, as the basis of the new industrial branch, 
namely the software industry. This point of view was met with sharp objections 
by many people, and Ershov had to defend his position for a long time and with 
much tenacity. This position, which later proved to be correct, is reflected by 
the term “technology” as applied to programming. 

Perceiving his leadership, Ershov understood all the responsibility for build- 
ing the foundation of the new discipline and distinctly saw the needs of the 
whole field. With respect to this he emphasized two problems. The first one 
is the problem of creating the “lexicon of programming”, that is a conceptual 
basis, a system of interconnected and formalized notions reflecting at a good 
level of abstraction everything needed for the process of program construction. 
A large part of Ershov’s work is in this subject. It is enough to recall his works 
related to the BETA system. The second problem is close to the first; it concerns 
the development of the theory, of the formal methods, of everything that can 
now be distinctly traced in the new methodologies and technologies of program 
design. In this direction Ershov has also done a lot. His contribution to the the- 
ory of program schemata will be discussed later, and meanwhile I would like to 
stress that he ever saw the link between the theory and the practice of program- 
ming and knew both how to draw a basis for theoretical models from practical 
results, and how to apply theoretical research to practical tasks. As early as 
the Alpha compiler, he was using the theory of memory economy which he 
and S.S. Lavrov had elaborated to construct corresponding optimizing transfor- 
mations. This work had further consequences. A large proportion of subsequent 
works from the Novosibirsk school on creating program models (linear schemata, 
multiple schemata, linear programs, large-block schemata, regular schemata) and 
on their application for proving correctness of optimizing transformations sprung 
from this source. Another example: heading the design of multi-processing and 
multi-programming system AIST, Ershov simultaneously initiated research on 
formal models of parallel programs. 

In 1977 Ershov published a splendid and, in some respects, unique book 
“Origins of Programming: Discourses on Methodology” . This book showed (this 
constitutes its special importance) how the investigation of practical problems 
leads to theoretical models and how the models assist in solving practical prob- 
lems. Monographs on programming, as we well know, quickly become outdated. 
But this book appears to be an exception from this sadly common rule: in 1990 
it was published in English. 

One of the main problems of any new trend is the training of professionals 
and researchers. With this respect as well, Ershov was a pioneer and leader. 
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He devoted a lot of time to educational informatics and its methodology, to the 
writing of textbooks and learning systems, to advertising the importance of these 
kinds of activity. He was the recognized leader in this area in this country. 

On the one hand, he was occupied by the problem of educating professional 
programmers and he dedicated a series of his works to this. On the other hand, he 
started the school informatics in this country, and here his activities were multi- 
faceted: lectures on TV, one of the first textbooks on informatics for secondary 
schools (this textbook has been translated into many languages of the USSR), 
organization of summer schools of young programmers, organization of a voyage 
of young programmers to the United States, and others. It is essential that he 
saw the unity of both sides: of the education of high-level specialists and of 
upgrading informational culture of the society starting in the school. 

Ershov was aware of his leadership and he saw the destiny and development 
of the new trend and the destiny of people who would work in that field as his 
own responsibility. He could defend the value of programming and programmers 
to the outside world. He had an excellent (and not common) feature: he valued 
the authority of knowledge, of mental outlook, of spirit, but not that of post and 
position, and he applied this attitude to himself. His statements were always 
thoughtfully and logically structured, he watched himself attentively and he 
never imagined that these statements should be taken as indisputable truths 
simply because they came from an “important person” . 

I cannot remember any case in which he, though being aware of his huge 
influence, took the stand of an oracle, which would have been respected only 
because he occupied a high position. 

I have already mentioned in what degree Ershov’s scientific results con- 
tributed to the formation and auto-identification of the new discipline. The 
definition itself of the spirit of that discipline, of its ethic, of its professional 
specificity are due to the works and to the activity of Ershov. The social out- 
look of programming in this country was formed thanks to the activity of such 
organizations as the Commission on System Software, Council of Cybernetics, 
Committee on Program Languages and Program Systems. All these bodies were 
headed by Ershov. His well-known works “Two faces of programming”, “Aesthet- 
ics and the human factors of programming” , “Programming, the second literacy” 
have clearly and vividly described the spirit and uniqueness of this new human 
endeavor. 

Ershov was also a leader in the social life of programmers. His leadership, 
unconditional and recognized by everyone, is also associated with his personal 
qualities. 

Possessing a true strategy of thought, he predicted the future of the new- 
born phenomena, clearly seeing “points of growth”. It is sufficient to recollect 
the works he once initiated: the implementation of one of the first specification 
languages SETL, technology for creating intellectual systems, theory of parallel 
programming, construction of the Shkolnitsa (Schoolgirl) system which was a 
methodologically grounded tool for teaching programming at school. Just from 
mere appearance of personal computers he understood their great future and 
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figuratively called the first PCs “the ancestors of mammals in the dinosaurs’ 
world of contemporary computers” . 

I hardly know anyone who could, like Ershov, enjoy the ideas of others. 
He listened to them attentively, independent of whether they came from a post- 
graduate student or from a professor, actively propagated them, assisted authors 
in realizing their ideas. Numerous are those for whom the assistance of Ershov 
was quite essential. Among them are E. Tyugu (Estonia), M. Tsuladze (Georgia), 
I. Velbitsky (Ukraine), D. Todoroy (Moldova), A. Terekhov (St. -Petersburg) and 
many others. To say nothing of us, Siberians. 

Thus, Ershov was both one of pioneers and a leader of national programming. 
While the times he lived in have primarily contributed to the first role, his 
outstanding personality has mainly contributed to the second one. 
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Abstract. The aim of this paper is to survey the advent and maturation 
of the theory of program schemes, emphasize the fundamental contribu- 
tions of A. A. Lyapunov and A. P. Ershov in this branch of computer 
science, and discuss the main trends in the theory of program schemes. 



This paper was written in commemoration of Andrei Petrovich Ershov, who 
exerted great influence on the development of theoretical programming, the the- 
ory of program schemes specifically. The choice of this section for discussion does 
not only display the author’s predilection. The key point is that the concepts 
introduced by A.P. Ershov as the basis for the theory of program schemes in the 
time of its coming into being have been consolidated in subsequent years along 
the trend predicted by him. It was intended that this paper would elucidate the 
facts. 

1 The Formation of Scientific Preferences of Andrei 
Ershov 

This formation took place in the 50s of the past century. The years were com- 
memorated by the appearance and development of domestic electronic comput- 
ers. There was a need in specialists for their designing and servicing. 

Moscow State University responded to the call at once. In 1950 the depart- 
ment of computational mathematics was set up in the mechanico-mathematical 
faculty. Teaching of the students in numerical analysis was one of the objectives 
set for the department. Another aim was training the students for using the 
newly born computers. In contrast to the first one, this task did not have any 
clear-cut outlines of solution. Initially, it was assumed that the use of comput- 
ers for solving mathematical problems would necessitate detailed knowledge of 
the machine design. This consideration influenced much the choice of disciplines 
included in the curriculum for those studying in the department, namely: radio 
engineering and electronics, electrical engineering, theory of mechanisms and 
machines, adding machines and instruments, drawing. The subjects enumerated 
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replaced fully such disciplines as the set theory, higher sections of algebra, func- 
tional analysis, mathematical logic (the theory of algorithms was not taught yet 
in those years). 

Naturally, in due course the things that were actually indispensable for the 
graduates of the department were determined and the curriculum got rid of 
unnecessary subjects, whereas the mathematical foundation was restored. 

Andrei Ershov became a student of the department of computational math- 
ematics in 1952. He was lucky, as the gaps in his mathematical education in the 
years of his studentship were eliminated with assistance of Alexey Andreevich 
Lyapunov, who assumed supervision over Andrei Ershov post graduate educa- 
tion. Alexey Andreevich drawn up a program of qualifying examination for the 
candidate’s degree satiated in mathematics and strictly followed its implemen- 
tation advising personally on the subjects included in the program. 

Let us go a couple of years back to 1952, when Alexey Andreevich accepted 
a position of professor at the department of computational mathematics. The 
event is noteworthy, as scientific life at the department livened up a lot. Andrei 
Ershov was then the fourth year student. 

His enthusiasm and gift of convincing helped him to turn many of students in 
the department into his belief in extraordinary future that lied ahead for the ma- 
chines and programming. In 1952/1953 academic year Alexey Andreevich read 
the famous course of lectures ’’Principles of Programming” (the relevant materi- 
als in a somewhat revised form were published only in 1958 m) to the students 
in the department. It was the first in the country course in programming that 
played the fundamental role in the development of a new branch of knowledge, 
i.e. programming. 

A new view on formalization of the concept of algorithm as such was pre- 
sented, proceeding from convenience of its use when solving practical problems. 
Meanwhile, the already existent formalizations of the algorithm concept (such 
as Turing’s machines, Markov’s normal algorithms) were aimed exceptionally at 
studying the nature of computations rather than practical application. In the 
course read by Alexey Andreevich a programming language was suggested, which 
was precursor of the currently used high-level languages; the language was called 
the operator language. Its introduction made it possible to describe techniques of 
programming. The operator language and the relevant programming techniques 
were integrated under the name of the operator method. 

The operator language was not formalized. However, the problems of pro- 
gramming could be actually discussed, i.e. for the first time programming was 
treated as a branch of science with its own problems. Two problems were selected 
by Alexey Andreevich for the principal ones, namely: 

— automation of making up programs; 

— optimization of programs that were initially made up. 

The problems were considered mutually interrelated, though each of them could 
be studied separately. 

Alexey Andreevich attracted students in the department, Andrei Ershov 
among them, for coping with the first task. He offered that the operator Ian- 
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guage is used as support one. Construction of the so-called programming pro- 
gram was planned; the program receiving for an input a description of algorithm 
in the operator language was aimed to transform it into the program executing 
the algorithm. Conceptually, the programming program was to be assembled 
from blocks performing individual functions. Andrei Ershov was entrusted with 
construction of arithmetic block. 

The work was the initial step in the studies relating to construction of trans- 
lators, the studies that ran all through Andrei Petrovich subsequent activities 
in programming. The works in this trend are enumerated in |7]. The evolution 
of his ideas and techniques for constructing the translators is discussed in the 
preface article by I.V. Pottosin [Z] . It is worth noting that already in that initial 
work the idea arose that the memory space of the programs should be opti- 
mized (refer to jl]). It was the first manifestation of the global intention — to 
apply optimization techniques to the made up programs along the process of 
translation. 



2 Early Investigations in Theoretical Programming 

They were directed by A. A. Lyapunov and pertained to the second problem. 
A. A. Lyapunov started from the following requirement: mathematical solution 
of the program optimization problem should actually rely on strict definition of 
the program as such, its structure and functioning, specifically. Only then one 
can speak of the function computed by the program and, accordingly, introduce 
the concept of functional equivalence of programs by using the requirement of co- 
incidence of the functions realized by the programs. Optimization of a program is 
performed by means of its equivalent transformations (e.t.), i.e. transformations, 
which retain the function realized by the program. Thus, the task of constructing 
the program e.t. is brought to the forefront after the program formalization. 

Alexey Andreevich assumed that program formalization may be performed on 
the base of the operator language. It is in this way that the task was formulated 
for Andrei Ershov. Then A. Ershov was his post graduate. 

Intuition prompted that the program formalization taking a full enough ac- 
count of actual program properties, is a new universal definition of an algorithm. 
This fact was established by A. Ershov in 1958 and published in m- He intro- 
duced the concept of operator algorithm and proved that all Markov’s normal 
algorithms are realized by the operator algorithms. 

We shall turn now to the task of constructing the program e.t. According 
to mathematical tradition this task is treated as follows: one shall find an e.t. 
system, which is complete in a given class of programs. The completeness of an 
e.t. system implies that for any two equivalent programs belonging to the given 
class there exists a finite chain of transformations belonging to the system that 
transforms one program into the other. Clearly, such system is the best solution 
of the task considered. As only solvable e.t. systems are of practical interest, their 
search ranks as e.t. problem. But then the necessary condition for its positive 
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solution is decidability of the equivalence problem; this means that there should 
exists an algorithm that recognizes the equivalence of programs. 

Note that approximate solutions of e.t. problem, i.e. designing of incomplete 
e.t. systems that could be used in practice, are of much interest as well. 

A. A. Lyapunov assumed that one of possible ways of its solution is in con- 
structing e.t. using not the programs as such, but their models, i.e. program 
schemes. The logic schemes of the programs he considered in two ways: as an 
algorithm description and as an algorithm scheme description. In the first case 
all operators used in the logic scheme and logic conditions are made specific. In 
the second case their specific definition is omitted, only the places occupied by 
them being fixed and a relation of scheme equivalence is defined. 

In general, A. A. Lyapunov intention was as follows. As the structures of pro- 
gram and its scheme coincide, each transformation of the scheme is the transfor- 
mation of the program, modeled by the scheme. Let us assume that the equiv- 
alence of schemes implies the equivalence of programs modeled by the schemes 
(The first equivalence is called the equivalence approximating the second one). 
In this case, if scheme transformation is equivalent, then it is equivalent for the 
program modeled by the scheme, as well. Thus, each e.t. system for schemes 
is the same for the programs, being the approximate solution of program e.t. 
problem. And the best solution is an e.t. system, which is complete in the set of 
program schemes. So, the scheme e.t. problem is converted to the fundamental 
problem for program schemes. And here, as for programs, the necessary condi- 
tion of its positive solution is the decidability of scheme equivalence problem in 
given class of schemes. 

The following task was formulated by A. A. Lyapunov for his post graduate 
Yu.I. Yanov: to define approximate equivalences in the set of operator schemes, 
introduced by A. A. Lyapunov, and to solve for them the scheme e.t. problem, 
considering some class of schemes. The investigation, executed by Yu.I. Yanov 
in m offers the new scientific direction, which was named theory of program 
schemes, and the operator schemes turned to Yanov schemes. 

Let us consider in more details this first result obtained in scheme theory by 
taking the formal concept of Yanov schemes improved by A.P.Ershov in jl] and 
labeling functions as they were modified by the author in m- 

Program schemes are defined over some finite alphabets Y and P. The ele- 
ments from Y and P are called operator symbols and logical variables respectively 
(each variable can be evaluated either by 0 or by 1). 

A program scheme (or simply scheme) is represented by a finite directed 
graph. Two nodes of the graph are distinguished: the entry node, which has 
only one outgoing edge and has no incoming edges, and the exit node, which 
has no outgoing edges. The other nodes of the graph are either transformers or 
recognizers. Each transformer has one outgoing edge and is associated with an 
operator symbol from Y . Each recognizer has two outgoing edges marked with 
0 and 1; it is associated with a logical variable from P. 

An example of a program scheme is depicted in Fig. 1. This scheme corre- 
sponds to the algorithm that computes nl for n > 0 (see Fig. 2). 



12 



R.I. Podlovchenko 




Fig. 1 Fig. 2 

The functional description of a scheme is related to the process of its execu- 
tion, which consists in traveling through the scheme accompanied by the accu- 
mulation of a chain of operator symbols. The corresponding path is determined 
by a priori given labeling function, which is defined as follows. 

Let 

X = {x\x: P -)■ {0,1}}. 

The elements of X are sets of values of all logical variables. Words in the alphabet 
Y will be referred to as operator chains. The labeling function is a mapping of 
the set Y* consisting of all operator chains into the set X. Denote by £ the set 
of all labeling functions. 

Let G be a scheme and /r be a function from £. The execution of the scheme G 
on the function p begins at the entry node of the scheme with the empty operator 
chain and consists in tracing the scheme. The passage through a transformer is 
accompanied by adding from the right an operator symbol corresponding to 
this transformer to the current chain. The passage through a recognizer does 
not change the current chain. Let h be the current chain and p be a variable 
assigned to the recognizer. Then, the value of the variable p is extracted from the 
set ph, and the tracing is continued along the edge marked by this value. The 
scheme execution is completed when the process reaches the exit of the scheme. 
In this case, the scheme G is said to stop on p, and the result of its execution is 
the operator chain accumulated. 

In [12 7 J Yu.I. Yanov considered a parametric set of equivalences of schemes 
over basis Y, P. Parameter denoted by s was called a shift distribution in Y; it 
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induces the set of labeling functions denoted by Lg. By definition schemes G\ and 
G 2 are equivalent for the given s, if and only if they stops on the same functions 
from Lg and chains obtained for a given function coincide. The fundamental 
result of m is Theorem 1. 

Theorem 1. Whatever is a shift distribution in Y for the equivalence induced 
by them both problems (of equivalence and of e.t.) are solved in the class of 
schemes over Y, P, where each operator symbol occurs at most once. 

Decidability of both problems for arbitrary schemes over Y, P was proved 
later in m- 

3 To the Characteristic of First Results in Theoretic 
Programming 

The result obtained by A. Ershov in m, placed the proposed formalization 
of a program among other formalizations of an algorithm, the mere fact of it 
being important. Besides, he changed the attitude towards the construction of 
program e.t. using their schemes. Really, all computable functions are realized by 
the programs, hence, the equivalence problem is not decidable for them, the fact 
being mentioned in |24| . This fact implies undecidability of e.t. problem in the 
set of all programs. Thus, the following alternative arises: either to find classes 
of programs with decidable equivalence problem and search for them an exact 
solution of e.t. problem or to restrict oneself to its approximate solution. So, the 
modeling of programs by schemes takes on the status of practically necessary 
task. 

Let us discuss the results obtained by Yu. I. Yanov in m- 

Intuition prompted that the equivalences proposed above approximate the 
functional equivalence of programs. To prove this hypothesis one shall define the 
concept of program as such. 

Below we introduce two notions: a semantics of basis Y, P and an abstract 
program induced by them. 

A semantics of basis Y, P denoted by cr is a complex consisting of 

— a set the elements of Yg. are called states; 

— functions ay : Sa — >■ , y &Y; 

— predicates ap : — >■ {0, 1}, p G P. 

The process of executing a scheme G on pair (<t, ^o)> Co S E^, is defined as 
follows. It begins at entry node of the scheme with the state Co and consists 
in tracing the scheme. The passage through a transformer with symbol y is 
accompanied by transformation of the current state C into state ay{f). The 
passage through a recognizer with variable p does not change the current state 
C; the tracing is continued along the edge marked by ap{(). The scheme execution 
is completed when the process reaches the exit of the scheme and then the current 
state is the result of the execution. Scheme G accompanied with a semantics a 
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is called an abstract program] this program computes the function which maps 
the set Scr into itself. Two abstract programs are equivalent if and only if they 
realize the same function. 

Now, for example, let us take the Yanov scheme equivalence induced by the 
shift distribution s, for which Lg = C, being called a strong equivalence. The fact 
that the strong equivalence approximates the equivalence of abstract programs 
is established in Theorem 2. 

Theorem 2. Two schemes over basis Y, P are strongly equivalent if and only if 
they induce equivalent abstract program for any semantics ofY,P. 

For the first time the fact was established in PI- 

The investigations carried out by Yu.I.Yanov precede the advent of the fi- 
nite automata notion. The connection between the Yanov schemes and a finite 
automata is given in the following. 

Theorem 3. Whatever is a shift distribution in Y , the equivalence induced is 
reduced to the equivalence of finite automata. 

For a strong equivalence this fact is established in |2^; for the others it follows 
from [2T| . 

4 On Some Other Tasks of Theory of Program Schemes 

We shall mention from the first the task of an economy of program memory, that 
was considered by A.P. Ershov, and then the tasks to which he called attention. 

The variables used by computer program are beyond the abstraction level of 
Yanov schemes. To deal with the issue of program memory space optimization 
new class of schemes of special kind was introduced. By using these schemes it 
is possible to represent explicitly program data-flow, since for each action the 
variables-arguments and the variables-results are specified. Informal description 
of such scheme was presented by A.P. Ershov in [T], formal definitions were 
suggested later by S.S. Lavrov (see [H]). The contribution of A.P.Ershov and 
S.S. Lavrov to the solution of the problem of program memory space optimization 
is described in detail in jB]. 

A.P. Ershov induced also active investigations of another kind of schemes, 
namely, standard schemes of programs |5]. In such schemes variables occurred 
program are represented explicitly, but unlike Lavrov schemes above the equiv- 
alence and e.t. problems for standard schemes are considered as principal ones. 
The investigations of standard schemes are expounded very fully in jS]. 

Extra attention to standard schemes is due to their generic property: most 
positive results and algorithms obtained for standard schemes can be transferred 
immediately with slight modifications to real computer programs. To make sure 
of this we shall recall informally the concept of standard scheme. 

Programs modeled by standard schemes are ALGOL-like ones, in which the 
description of variables, input- and output data are skipped. The programs are 
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constructed over the basis consisting of assignment operators and Boolean ex- 
pressions by using all known operations of operator composition except for the 
procedure operator. An example of such a program is given in Fig. 2. The trans- 
fer from a program to a standard scheme is realized by replacement of concrete 
operations and relations used in basis operators of assignment and, accordingly, 
in Boolean expressions by functional and predicate symbols respectively; these 
symbols retain the arity of operations and relations. The constructions obtained 
from concrete operators and Boolean expressions are called operators over mem- 
ory and predicates over memory. The structure of a scheme coincides with the 
control-flow of the corresponding program inducing the scheme. Fig. 3 provides 
the standard scheme constructed for the program depicted in Fig. 2. 




Fig. 3 

Now we shall describe how standard schemes operates. Let i be an interpre- 
tation of functional and predicative symbols, replacing concrete operations and 
relations. Interpretation i translates the scheme to the i-program. The function 
realized by the i-program is defined by the same rules that define the function 
realized by the initial program. 

Two standard schemes are equivalent if and only if for any interpretation i 
they give i-programs realizing the same function for the given interpretation. 
And, as there is an interpretation transforming the scheme into the initial pro- 
gram among interpretations i, the equivalence of standard schemes approximates 
the functional equivalence of programs modeled by these schemes. This fact en- 
sures that the results obtained for standard schemes according to equivalence 
and e.t. problems are applicable to real programs. 
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Describing contemporary state of theory of program schemes in A.P.Er- 
shov posed some problems of the theory. The equivalence problem has an im- 
portant place among other problems. 

The study of standard schemes began with displaying some certain classes 
of schemes, for which the equivalence problem is undecidahle. This was estab- 
lished in mm . Therefore it was essential to find out the classes of schemes for 
which the equivalence problem is decidable. The approaches to the research on 
this task are described in m- These approaches are based on imposing some 
specific requirements on a semigroup of basic operators or the scheme struc- 
ture. Both approaches seem quite natural. But A.P.Ershov described also some 
new implicit approach. In essence it is as follows. The functional equivalence 
considered above is defined in terms of final results computed by the schemes 
under consideration. A.P Ershov introduced the concepts of history of scheme 
computation and equivalence relations on the histories. This new type of scheme 
equivalence is worthy to be a subject of further research if and only if it is 
stronger than functional equivalence (for example, the logic-term equivalence, 
discussed in [Sj, satisfies the requirement). 

In |15] it was ascertained that equivalence stronger than functional is reducible 
to the functional equivalence in some certain subclass of schemes. 

In fact, for logic-term equivalence this reduction was noticed in |26) . 

A.P. Ershov attracted attention to the following problem: for program sche- 
mes specific approach has to be developed to construct complete e.t. systems. 
Theory of program schemes starts from mathematical logic, where complete 
systems are constructed traditionally. The means used by mathematical logic 
are as follows: a formal calculus is designed; its objects are formulae; in each 
inference rule only formulae are used. But in case of schemes the role of formula 
is assumed either by a scheme or a fragment of scheme, i.e. object not being a 
scheme. Therefore, the task mentioned above arises. An example of new approach 
was demonstrated by A.P.Ershov in [4]. The author position will be elucidated 
below. 

5 On the Logical Foundations of Program Scheme Theory 

They are based on the ideas developed by A. A. Lyapunov, i.e. the program sche- 
mes are created for construction of program e.t., and were supported by Yu. I. 
Yanov and A.P. Ershov in the works, we mentioned above. Being specified as 
concepts, they are as follows. 

Concept 1. Formalization of a program, the description of the program struc- 
ture and functioning, as well as definition of the program equivalence, is the 
initial point for constructing the program schemes. 

Concept 2. The definition of a program scheme consists in the description 
of its structure and functioning and the introduction of the scheme equivalence. 
These components obey the following requirements: 

A. The structure of the scheme coincides with the structure of the program 

modeled by the scheme; 
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B . The equivalence of the schemes implies the equivalence of programs modeled 

by the schemes, i.e. equivalence of schemes approximates the equivalence of 

programs. 

These conditions follow from the primary concept. In fact, when the require- 
ment a), is satisfied, each transformation of the scheme is the transformation 
of the program modeled by the scheme. The requirement b). guarantees that 
any transformation which preserves the equivalence of schemes is the equivalent 
transformation of programs. 

Concept 3. The e.t. problem for schemes is the principal problem in the 
theory. 

Concept 4. The modeling of program by schemes must be multiciphered, 
that is reached by means of variety of program scheme equivalence. Really, as 
the strict solution of scheme e.t. problem is approximate solution of program e.t. 
problem, then it is necessary to have the spaciousness for the choice of a suitable 
solution. 

Concept 5. The problem of scheme equivalence is the fundamental one. Let 
us remind that decidability of the equivalence problem in a class of schemes is 
the necessary condition for searching an e.t. system complete in the class. 

6 The Developing of the Logical Concepts of Program 
Scheme Theory 

We shall proceed with the branch of program scheme theory, called algebraic 
theory of sequential program models (or simply it theory of program models). The 
programs considered in this theory are ALGOL-like ones. They are classified by 
using/non-using operator procedure (see [I19llb| respectively). Below the facts 
are expounded relating to schemes of programs without procedure operator m 

Eng. 

In this case the formalized programs are the abstract programs, introduced 
above and constructed over basis Y,P. It is assumed that the semantics of basis 
Y, P is arbitrary. 

The structure of a program scheme coincides with the structure of the Yanov 
scheme. Hence, condition a), of Concept 2 is met. 

According to Concept 4 in the set of program schemes there is a parametric 
set of equivalences introduced m- It expanded essentially the equivalence set 
considered by Yu. I. Yanov. Each equivalence is induced now by two parameters, 
namely by 

— equivalence v in Y*; 

— subset L, where L C C. 

L)- equivalence of schemes Gi and G 2 is defined as follows: for any function 
from L each time when one of Gi, G 2 stops on this function, the other one also 
stops, and the results of their execution are two jz-equivalent operator chains. 
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The set of schemes over Y, P with the given (z/, L)-equivalence is called {ly, L)- 
model of programs. 

Following condition b). of Concept 2, it is necessary to select approximate 
equivalences from the set of all (z/, L)-equivalences. Any of them is called strict 
approximating equivalence if there is a non-empty set S of semantics of basis 
y, P, so that for any schemes Gi, G 2 over F, P the following assumption holds: 

Gi,G 2 are equivalent, if and only if for every semantics tr from S they are 
equivalent abstract programs on a. 

In [17] the following theorem is proved. 

Theorem 4. Semigroup equivalence is a sufficient eondition for L)- equiva- 
lence of scheme over Y,P to he the strict approximating one. 

By definition, (v, L)-equivalence is a semigroup equivalence, if v and L satisfy 
the following requirements: 

A. For any operator chains h\,h 2 ,h^, hi from Y* 

{hi ^ h2) & (/i3 hi) ^ - h^hi); (1) 

B. L consists of v-eoordinated funetions; a labeling function p, is called z/- 
coordinated if it satisfies the following condition: for any hi, h 2 from Y* 

hi ^ h2 ^ phi = ph2] 

C. L is elosed with respeet to shift operation, i.e. whatever are a function p from 
L and chain h from Y* , the labeling function p' defined by the identity 

p'g = phg, g GY*, 



also belongs to L. 

We shall interpret hi ^ /12 as the assertion ” hi , /i 2 are z^-equivalent operator 
chains” . 

Note that the equivalences of discrete processors discussed by A. A. Letichev- 
sky in m are the semigroup equivalences. 

As the strict approximation is stronger than the simple approximation de- 
fined above, the following question arises: can we possibly lose practically useful 
equivalences? The answer is given by Theorem 5. 

Let us consider the programs given in the formalization used in standard 
schemes. Denote by K the class of such programs constructed over a finite basis 
of assignment operators and Boolean expressions. According to definition given 
above, by transition from programs of class K to standard schemes corresponding 
to the programs each assignment operator is replaced by operator over memory, 
each Boolean expression is replaced by predicate over memory. Denote by Ki 
the standard scheme class obtained. 
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Suppose the equivalence in K\ is induced by such equivalence of programs 
from K which demands coincidence of program execution results on each vari- 
able used by programs. Further, if the assignment operators are replaced by 
operator symbols and the Boolean expressions are replaced by logical variables, 
then we obtain the Yanov schemes from the programs of K. Denote this class by 
K 2 - Let us now introduce the correspondence between the operator over mem- 
ory (the predicates over memory) used in K\ and the operator symbols (the 
logical variables) used in K 2 so that their prototypes coincide. In this way the 
correspondence between the schemes of Ki and schemes of K 2 is established. 

Theorem 5. It is possible to define a semigroup (y, L)- equivalence in K 2 so that 
schemes from Ki are equivalent if and only if the corresponding schemes from 
K 2 are {v, L)- equivalent. 

One of the main advantages of the semigroup equivalences is that they factor 
out the equivalences of standard schemes. But there are some other advantages. 

By definition, (i^i, Li)-equivalence is approximated by ( 1 ^ 2 , L 2 )-equivalence, 
if the latter implies the former. Suppose it takes place. Let us consider a class 
of abstract programs. Suppose their equivalence is approximated by {vi,Li)~ 
equivalences, i = 1,2, and for both equivalences complete e.t. systems exist, T\ 
is the system for the first, T 2 is the system for the second equivalence. Both 
systems are not complete in the class of programs but Ti is richer than T 2 . 

Thus, in the set of program models we may improve the system of e.t. pro- 
gram not leaving this set. The possibility gives rise to the task: to search for 
sufficient indications for approximating one equivalence by another. The prob- 
lem mentioned is considered in m- 

Now we turn our attention to the equivalence problem for schemes. The 
latest survey on this topic was presented by V.A. Zakharov in the conference 
MCU’2001 and published in [^. Hence, we restrict our consideration by the 
novel approaches to this problem and discuss the most significant results ob- 
tained so far. 

Let us emphasize that here we talk about the theory of program models only. 
One of the new aspects in studying the equivalence problem is systematic search 
for algorithms that besides checking the equivalence of a program scheme do 
it in a reasonable time. The point is that the early investigations were focused 
mostly on the decidability/undecidability of the equivalence problem and com- 
putational complexity of decision procedures was ignored very often. Decision 
procedures, whose time complexity is exponential, of the size of schemes under 
consideration were regarded as workable though quite inapplicable in practice. 
Since only those algorithms, whose time complexity is polynomial of the size of 
inputs are acknowledged to be efficient, the question arises as to whether it is 
possible to find out such algorithms by revising the known decidable cases and 
attacking new variants of the equivalence problem. 

Nowadays two novel techniques for designing efficient equivalence-checking 
algorithms are developed. Both methods go back to | 20I29| . 

The essentials of the first method are presented in Theorem 6 below. 
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Let us introduce some basic concepts. 

It is worth noting that the set Y* of terms along with concatenation operation 
may be thought of as a finitely generated semigroup. Its elements are generated 
by basic actions y, y GY; the empty term A stands for its neutral element. 

Let V be an equivalence relation on Y*, and L be the set of i/-coordinated 
functions from L. In this case we will say that (v, L)-equivalence is the equivalence 
w.r.t. the semigroup Y* supplied with v. 

A semigroup Y* supplied with v is called length-preserving, if Y* meets 
all requirements (1) (see theorem 4) and, moreover, whenever h and g are v- 
equivalent chains, then they have the same length. 

Given a length-preserving semigroup Y* and a chain h in Y* , we denote by 
[h] the equivalence class of h w.r.t. n, and by |ft.| the length of h. Clearly, the set 

E = {{[hi],[h2]) : \hi\ = \h2\, hi,h2GY*} 

is also a finitely generated semigroup. 

We consider some finitely generated semigroup W, which has o for binary 
operation and e for the neutral element. Suppose that U is a, semi-subgroup of 
W, and w~^,w* are some distinguished elements in W. Then a quadruple 

K = {W,U,w+,w*) (2) 

is called a criterial system for a length-preserving semigroup Y*, if there exists 
an integer fcp and a homomorphism (p from E to U, which satisfy the following 
requirements: 

Cl. 

[hi] = [h 2 ] ^ w~'~ o (p{{[hi],[h 2 ])) o w* = e 
holds for all pairs of chains /ii, / 12 ; 

C2. For every w from U o w* there exist at most fco left inverse elements from 
o U, i.e. the equation 

z o w = e 

has at most fco solutions z of the form w~^ o u, where u G U . 

Then we arrive at 

Theorem 6. Suppose that a length-preserving semigroup Y* has a criterial sys- 
tem (2) such that the identity problem ”wi = W 2 ?” is decidable in time t{m), 
where m = max(|wi|, |w 2 |)- Then the equivalence problem for schemes w.r.t. this 
length-preserving semigroup is decidable in time 

cin^{t{c 2 n^) + logn), 

where n is the size of schemes to be analyzed, whereas C\,C 2 are constants that 
depend on kg, the number of elements in Y and logic variables in P, and on 
homomorphism p. 
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This theorem, as well as its application to some specific length-preserving 
semigroup is presented in [29j . One of such semigroup operators, namely free 
commutative one, was studied earlier in | 20| . A free commutative semigroup Y* 
is characterized by the following property: chains hi and /12 are equivalent if for 
every y in Y the numbers of occurrences of y in h\ and /i 2 is the same. The 
equivalence of schemes w.r.t. free commutative semigroup is decidable in time 
cn^ logn, where n is defined as in Theorem 6, whereas c depends on the number 
of logical variables in P only. 

The technique used in |29] is based on the study of algebraic properties of 
semigroup Y* supplied with the equivalence of chains. 

An alternative approach was introduced by the author m- 

It is based on the computation of invariants for equivalent schemes. By ap- 
plying this method the following result was obtained in [2^ . 

Theorem 7. The equivalence of schemes w.r.t. semigroup Y* , which is both 
left- and right- contracted is decidable in polynomial time. 

By a left- (right-) contracted semigroup we mean any length-preserving semi- 
group Y* for which the supplied equivalence v is decidable and which satisfies 
the following properties 

hhi - hh2 ^hi^h2 
hih^h2h^hi - h2 

It should be noted that a free commutative semigroup is both left- and right- 
contracted. 

Now we think that the task of attracting attention to new trends in studies of 
equivalence problem is completed and we turn to the presentation of the latest 
achievements in the research on equivalent transformations in the framework of 
program models m- 

The means applied by us for construction of complete e.t. system involve 
the development of suitable formal calculus as before. Its formulae are pairs of 
scheme fragments. The scheme fragment is defined according to [2^, any scheme 
is considered as a fragment of some specific type. 

The fragments belonging to the pair must be coordinated. Only then it is 
possible to replace in a scheme one of such fragments by the other and result of 
this replacement will be the scheme again. 

So each pair of fragments, when coordinated, induces the set of scheme trans- 
formations. In case when this set consists of equivalent transformations only, the 
fragments belonging to the given pair are called equivalent. 

A calculus of scheme fragment pairs must satisfy two requirements: 

1. it has the unique inference rule which is the replacement of one fragment by 

the other; each axiom is a decidable set of equivalent fragment pairs; 

2. for each equivalent schemes G\,G 2 there exists a finite sequence of trans- 
formations induced by axioms that transforms the pair (Gi,C? 2 ) to the pair 

(G2,G2). 
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The formal calculus described (and e.t. system induced by it) is called finite if 
only finitely many axioms are used. 

It should be noticed that the cases, when an axiom contains all pairs of 
equivalent schemes and when an axiom inserts an additional labeling to a scheme 
(as it takes place in a) do not fall under this definition. In |22| by using invariants 
of equivalent schemes we prove the following 

Theorem 8. If the equivalence of schemes over Y, P is induced hy a semigroup 
Y* , which is both left- and right- contracted, then there exists a finite e.t. system, 
which is complete in this set of schemes. 

This generalizes many known results on equivalent transformations. 

We conclude our paper with the following summary: the development of the 
program scheme theory realized in program model theory lends credence to the 
fruitfulness of its basic concepts. Furthermore, program schemes fit naturally 
into the row of computational models both by main research problem and by 
inter-reducibility of these problems. 
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The computing science is about computations. But what is a computation? 
We try to answer this question without fixing a computation model first. This 
brings up additional foundational questions like what is a level of abstraction? 
The analysis leads us to the notion of abstract state machine (ASM) and to the 
ASM thesis: 

Let A be any computer system at a fixed level of abstraction. There is 

an abstract state machine B that step-for-step simulates A. 

In the case of sequential computations, the thesis has been proved from first 
principles; see ACM Transactions on Computational Logic, vol. 1, no. 1 (July 
2000), pages 77-111. Of course ASMs are not necessarily sequential. In a dis- 
tributed ASM, computing agents are represented in the global state. New agents 
can be created, and old agents can be deactivated. There could be various re- 
lations among agents and various operations on agents. The global state is a 
mathematical abstraction different from the conventional shared memory; it may 
be, for example, that the agents communicate only by messages. The moves of 
different agents form a partially ordered set. Concurrent moves cause consistent 
changes of the global state. 

Often a formal method comes with a reasoning system. If this is your idea of 
a formal method then the ASM approach is not a formal method. It is system 
informatics where modeling is carefully separated from formal reasoning. Notice 
that formal reasoning is possible only when the raw computational reality is 
given a mathematical form; ASMs do the modeling job. 

The separation of modeling and reasoning concerns does not undermine the 
role of reasoning. The ASM approach is not married to any particular formal 
reasoning system and is open to all of them. It is usual for ASMs to have integrity 
constraints on states. ASM programs can be enhanced with various pre and post 
conditions. ASM-based testing can be enhanced with model checking. The most 
important direct application of ASMs is their use as executable specifications. 
This makes (totally as well as partially) automated reasoning relevant. 

For more information on abstract state machines see the academic ASM 
website 

http : //www . eecs . umich . edu/gasm/. 
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Abstract. Many computational problems are algorithmically unsolv- 
able. How well this fundamental assertion of computability theory is 
based — that is the main question considered in the paper from a pro- 
grammer’s view. 



Introduction — Where Does the Border between Natural 
and Formal Languages Lie? 

To begin with — a comment to the Russell’s ‘village barber’ paradox. A man 
has many aspects. When at home he eats, sleeps, in the morning washes and 
possibly shaves himself and after breakfast goes to the work. At work he being 
the barber receives his clients, cuts their hair and shaves them. He would violate 
his promise only if he sat in the barber’s chair and simultaneously stood nearby 
and shaved the man sitting there. 

One may oppose that all said above is a game with notions taken from the 
human mode of life and reflected in natural language. However G. Cantor himself 
expressed the concepts of the set and membership using the words like “collec- 
tion”, “intuition”, “intellect”, “the whole (indivisible)”, which differ from the 
common ones maybe by a slightly higher style. He simply has had no other 
means just as we have not got them still. The chance for a set to be its own 
member is by no means better than for a barber to receive himself as a client. 

The attempts taken at the first half of the XX century to remove contradic- 
tions from the set theory have led to the seemingly successful creation of the 
axiomatic set theory. The proper classes introduced in the theory serve as sub- 
stitute for all ugly sets (undesirable barbers). Since then Cantor’s set theory got 
the attribute “naive”. I try to show that the traditional computability theory 
has the touch of naivety too. 

The main trouble with the axiomatic approach is in lacking of a model for 
the whole set theory. The theory with proper classes may be considered as a 
meta-theory for the one of the common sets. It contains the class playing the 
role of a subject domain for the latter theory. What may serve however as such 
a domain for the meta-theory? Just in this vicinity the fuzzy border lies between 
natural language together with common sense and formal means for expressing 
the scientific concepts. 
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In my opinion the problem to be discussed lay on the informal side of the 
border. The famous Church’s thesis says that all known ways to formalize the 
algorithm notion are essentially equivalent with each other and that they all 
correspond to the intuitive notion of effectively computable function. Mind that 
in the second part of this statement the correspondence is considered as merit 
of formal definitions, not of informal notion. 

1 The Human Factor 

A human whatever his occupation may be hardly has no personal view on the 
subject of the occupation. E. g. every researcher has probably his own concept of 
the continuum: either it is a set “composed” in a manner from all real numbers or 
something else — say, a kind of memory where all rational numbers are written 
and there are places in between for the other, irrational, numbers when they 
come into consideration. 

If the researcher tries to formulate this concept then a description of a count- 
able set arises — no other sets may be described. He may tell to his colleague the 
description and the latter says: “But this description is not full, since departing 
from it I may point out an object of the same kind differing from all objects falling 
under the description” (here lies the essence of the diagonal method which serves 
as a mean to prove many fundamental mathematical assertions). The reaction 
may be as sharp as “Nobody is interested in your object, in any case not me” . 
This may be answered differently too, but there still remains the problem — to 
what extent the diagonal method is constructive and convincing or broader — 
the problem of a personal view on the science and its substances. 

2 Abstract Computation 

In the traditional computability theory (see, e. g., |2j, ch. 5, other sources not 
quoted here contain analogous concepts and conclusions) a process of computa- 
tion starts from some input data and ends in a favourable case with supplying of 
an appropriate result. An abstract machine is described which works over data. 
The process is usually divided in steps. On each step the machine executes just 
one elementary action, guided by a rule selected from a fixed finite collection. 
The current data are used — those available at the step beginning. The input 
data of the process serve as the current ones for the very first step. 

A check is made too on each step whether the process is completed with 
no guarantee that it occurs at some time. Even a man observing the machine 
functioning (what is not forbidden but with no right to interfere) hardly if at all 
can in general case predict the future development of events. 

The description of the sequence of rules which leads the machine to solving a 
problem, i. e. to getting a result tied in a specified manner with the input data, 
is called an algorithm of the problem solving. The algorithm may be considered 
as a function (in constructive sense of the word) usually built as a composition 
of a number of other functions. 
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Any abstract machine implements the idea of the potential infinity. Thus 
from any natural number n it is possible to pass to the number n+ 1. Regardless 
how many words in a finite alphabet are constructed there is a possibility to 
build a new word at any time. 

The recursion applies the same idea to function computation. If the required 
result is not yet got then the function may — directly or via some other func- 
tions — call itself to continue the computation. The current recursion level is 
equal to the number of started and not yet terminated function evaluations. 
One specific function or all of them together may be accounted in the level. The 
recursion depth is equal to the maximum recursion level reached in the course 
of a function evaluation. 



3 Is It Possible to Establish the Bound of the Recursion 
Depth? 

This question occupies one of the leading places in the computability theory. Let 
us try to find a sufficiently general answer, limiting ourselves to the case of end 
recursion when the pass on the next level might take place only as the last step 
in the current level. To this goal we need two auxiliary functions without the 
parameters. The function 

B{) = if T then T else B{) 

breaks immediately from the loop of recursive calls with the value T (‘true’), 
while the other one 

C( ) = if T then C{ ) else T 
sticks in the loop forever. 

Let us assume that a function S{A, X) with two parameters: a function A and 
its argument X — may be described and that it solves the “stopping problem” , 
i. e. supplies the value T if the evaluation of A{X) ends successfully and the 
value F (‘false’) — otherwise. The traditional computability theory asserts that 
such an assumption leads to a contradiction. 

The assertion has mainly the following proof. The function D is considered 
that predicts using S the result of the call D{X). After that the computation is 
directed along the path consisting of either the call of B if the endless compu- 
tation is predicted or the call of C — otherwise. In both cases the behaviour of 
either path and of the whole function contradicts to the prediction. Thus from 
the assumption on the function S the identically false result 

S{D, X) = -nS{D, X) 

may be deduced what leads to the conclusion that the function S with the 
required property cannot exist. 

This proof would be perfect if the function D which makes exactly all said 
above might be described. Evidently the description should look like this: 

D{X) = if S{D, X) then C{ ) else B{ ) 
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What is the value of the expression S{D, X) occurring within it? Acting straight- 
forwardly one may try to replace this expression by D{X) (since the latter may 
have only T as its value). However this trial leads to no result at all, since such 
a form of D sticks already within the condition of the right part of the function 
definition and neither of the branches may be chosen. May the roundabout ways 
help? 



4 The Static vs. Dynamic Approach to the Analysis of 
Algorithms 

While building the function S the static approach is based only on the analysis 
of the text of the function A description. It is assumed that the value of S may 
be bound with the argument X value either without any knowledge of the latter 
or with very weak assumptions on its properties. The dynamic approach implies 
the analysis of the whole evaluation of A{X) with the specific value of X. In the 
course of the process the properties of current data are looked through. 

Let us look at the definitions of functions B and C given above. Each of 
them contains the call of function being defined. Therefore both may formally 
be considered recursive. However by a slightly more attentive look it occurs that 
one of two branches of the inner conditional expression is never chosen. It allows 
to bring these definitions to the form: B{) = T and C{) = C{), in which B 
ceases while C remains to be recursive. This is a rather trivial example of static 
analysis. 

The notions of current data, current recursion level are intrinsically bound 
with the execution process and therefore should be considered dynamic. The 
notion of recursion depth is bound with the latter of them and seemingly should 
be taken dynamic too. However from the example of recursive definition of the 
function factorial: 

factorial{N) = if = 0 then 1 else N * factorial{N — 1) 

is rather evident that the recursion depth being equal to the value of the ar- 
gument N (it may be easily proved by induction) may be sometimes found or 
estimated statically. But in the general case it is not so. E. g. the recursion depth 
of the easily defined function hotpo: 

hotpo{N) = if TV mod 2 = 0 then hotpo{N = 2) 

else if = 1 then 1 else hotpo{5 * A^ -I- 1) 

is very hard to estimate (I do not know whether someone has a luck to do it). 

The question may be treated a bit more formally (but with the same result) . 
The recursive function invariant (its least fixed-point) is the union of an infinite 
sequence of the continuing each other functions. Its /c-th element corresponds 
to the execution with the recursion depth k. If a finite form of the invariant is 
found then it provides the possibility of the static analysis. If however such a 
form is not found then the dynamical analysis becomes obligatory. It relies on 
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the termination of the execution with the simultaneous obtaining both the result 
and its connection with the input data, i.e. in a sense on good luck. 

The assumption that a function property may be always revealed statically 
should be declined since just this approach leads to the universally false asser- 
tion. The dynamic approach brings the computation of S{D, X) into endless 
recursion: the function S calls D and that one again demands to find the value 
of S{D, X). It is essential that this conclusion is obtained statically departing 
from the text of the function D description and from the choice of the dynamic 
approach to the function S implementation. The endless looping ruins the main 
idea of the diagonal method — to obtain the result with properties contradict- 
ing to predicted ones. As regards to the pair (Z3, X) the title question of section 
3 may not be stated in a manner leading to any answer at all (the barber is 
bearded and the question — whether he shaves himself or not — looses any 
sense). Thus it is proved that the function S may be only partial: there exist 
functions (namely D) for which the static prediction of termination is impossible 
and the dynamic one falls in a deadlock because of peculiarities of the function 
structure. 

So the diagonal method of reducing to a contradiction being so tempting 
in theory has not worked in practice. The discord between two colleagues in 
connection with the same method is coming to mind. However in books and 
papers it remains directly or not the leading method in proving assertions that 
algorithms of solving many mass problems are impossible. In that case such 
problems are called algorithmically unsolvable. 

The guile of the intention — to compose the function D so that it behaves in 
spite of the prediction made by the function S — is not tightly bound with the 
situation. The places where B and C are called may be interchanged to make D 
to behave in accordance with the prediction. However that does not make the 
prediction possible. 



5 A More General Case 

Any function calling itself to bring a judgement whether it has some definite 
property is not shielded from endless looping. Let the algorithms either having 
or not having a property P do both exist and a function similar to D inherits 
the property from the chosen branch. The so called Rice (or Uspensky-Rice, see, 
e. g., P, §56) theorem states that no algorithm recognizing such a property is 
possible. In its proof the Z3-like function is used. The proof is as vulnerable as 
the previous one and on the same reason — the looping by the dynamic analysis 
of the couple S + D behaviour arises inevitably before any prediction is made. 
This vulnerability lies on the surface being detected statically. 

Only very seldom and for a very simple algorithms their properties may be 
found without their execution. Unfortunately such algorithms are typical for the 
publications on the “proof of programs correctness” . In general case to determine 
that the result of an algorithm execution is bound in a certain manner with the 
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input data is possible only while looking through and analyzing the algorithm 
action with a certain variant of the data. 

Therefore instead of algorithmic unsolvability it is better to speak about 
algorithmic semi-solvability of almost all or of great many mass problems — the 
properties of the result are established together with its obtaining if this ever 
occurs. 

6 Self- Applicability 

In the traditional theory the first place among these problems occupies that 
of self-applicability of functions (see [T], §47). A function is called either self- 
applicable or self-inapplicable depending on its applicability to its own descrip- 
tion. The problem is stated: to build a function D, which is applicable only to 
the descriptions of all self-inapplicable functions (a variant of Russell’s paradox). 
The trial is made: to prove using the diagonal method that the function building 
is impossible. 

The assumption that D is self-applicable i. e. applicable to its description 
D' would mean in view of requirement to D that D' describes an self-inappli- 
cable function. The arisen contradiction leads to the conclusion that D is self- 
inapplicable. The assumption that lack of self-applicability can be revealed stati- 
cally again leads to contradiction. But by the dynamic approach no contradiction 
may arise. Indeed the absence of self-applicability of D means that one should 
infinitely long wait for the result of application of D to D' , i. e. the second 
outcome of the prediction never will be available. In the same way the Russell’s 
barber never meets the question — to shave or not to shave himself as a client. 

7 The Freedom as a Realized Necessity 

In [T|, the remark to §47.2.1, the non-admittance of a too large freedom in 
the context of set-theoretical conception is noted — it is impossible without 
falling in contradictions to combine freely any ‘objects’ in ‘sets’ which in turn 
are treated as ‘objects’. However, on some reason there never arises the question 
whether without any limitation one may build ‘words’ — the descriptions of the 
‘algorithms’ and to transfer these words on input of any algorithm. 

Maybe in the context of algorithm-theoretical approach the freedom may 
turn to be superfluous too? Let e. g. a normal algorithm is written assuming 
that its input word consists of two parts with a delimiter between them. Is there 
any reason to allow its application to the word containing no such delimiter? In 
other words — it is not reasonable to violate the simplest and well known to 
programmers limitation on types and to call a function of two parameters with 
only one argument. 

Let us look from this point of view at the problem of self-applicability of 
the universal algorithm W ([T], §48.2.1; |2], p. 248) transforming the pair (A, P) 
into the result of applying an arbitrary algorithm A to a, word P. What ap- 
pearance the input word P must have in this case taking in mind the types? 
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Self-applicability demands this word to have the form (W, Pi). It will not be 
complete if Pi differs from P. All this means that the word P must satisfy the 
equation P = (lA, P) obviously having no finite solution. This result may be con- 
sidered as a static analogue of the assertion that the endless looping is inevitable 
in the attempt to prove dynamically using diagonal method that recognition the 
self-applicability of the universal algorithm is impossible. 

In essence the “diagonal” function D and the like ones are endowed with the 
valuable meaning not in greater extent than verbal constructions used in the so 
called “semantic” paradoxes (H, p. 9-10). 

So one of the most expressive form of the “liar paradox” refers to the text 
two pages of which look like this: 



The assertion (**) 
is true. 


on the p. 2 
(*) 


1 





The assertion (*) on the p. 1 
is false. (**) 

2 



It is generally accepted that paradoxes, which use references to other pages of 
the text, to labels like ‘(*)’ at the reference place etc., lie out of the scope of the 
logic. However this motivation weakly agrees with the practice of mathematical 
publications. 

It is also possible to admit that the assertions unable to be neither true nor 
false have no sense expected from the logical propositions. 

But in solving this paradox it is necessary to take into account also that one 
of the assertions (*) and (**) was written before the other and therefore is the 
forecast of a future event. Whether such forecasts are acceptable in mathematics 
and if so have we a right to expect that they will be realized — that is the 
question deserving attention. The theory of approximation using the limited 
quantity of data is a field of mathematics, where the huge amount of conditions 
and counterexamples arises. 

Let us return to the “diagonal” constructions. In a prophecy-free mathemat- 
ics it is difficult to wait that an S'-like function might be successfully applied to 
the analysis of algorithms appearing only after it was described. 

It is generally accepted in physics that an observer may influence on the 
process observed — the presence of the observer makes the system not isolated. 
Something like we find in foundations of mathematics as well. By describing the 
field in which a mathematical theory is developed or a computational process 
takes place a person changes this field, brings a new element in it. Only catching 
this element he himself or somebody else can carry out the diagonal construction. 
As it was shown this construction concerns rather indirectly to the initial field. 
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8 Conclusion 

In this paper written on the minimal level of formalization the next assertions 
are grounded: 

- just this level is appropriate to the analysis of the problems taken from the 
so called foundations of mathematics; 

- the contradiction grounding the impossibility of some algorithms arises only 
with the static approach; 

- the dynamic approach leads only to the impossibility to judge definitely on 
these algorithms behaviour when the diagonal method is applied; 

- some limitations generally accepted in set theory and in programming should 
be observed in computability theory as well, their violation leads to the 
unpredictable consequences; 

- the researcher’s influence on the results of considered problems need to be 
taken into account, especially in the case of the self-application of an algo- 
rithm. 
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Abstract. Proving formulas in propositional logic can be done in dif- 
ferent ways. Some of these are based on of resolution, others on binary 
decision diagrams (BDDs). Experimental evidence suggests that BDDs 
and resolution based techniques are fundamentally different. This paper 
is an extended abstract of a paper [3| in which we confirm these hndings 
by mathematical proof. We provide examples that are easy for BDDs and 
exponentially hard for any form of resolution, and vice versa, examples 
that are easy for resolution and exponentially hard for BDDs. 



1 Introduction 

We consider formulas in propositional logic: formulas consisting of proposition 
letters from some set V, constants t (true) and f (false) and connectives V, A, 

— >■ and -f-i-. There are different ways of proving that a given formula is a tautology. 
In the automated reasoning community resolution is a popular proof technique, 
underlying the vast majority of all proof search techniques in this area. 

In the VLSI and the process analysis communities binary decision diagrams 
(BDDs) are popular |2I5| . BDDs have caused a considerable increase of the scale 
of systems that can be verified, far beyond anything a resolution based method 
has achieved. On the other hand there are many examples where resolution 
based techniques out-perform BDDs with a major factor. Benchmarks showing 
out-performance in both directions have been described in [^. 

However, these benchmark studies only provide an impression for the particu- 
lar proof strategy used, saying very little about the real relation of resolution and 
BDDs. Actually, only given such benchmarks it can not be excluded that there 
exist a resolution based technique that always out-performs BDDs, provided a 
proper proof search strategy would be chosen. So, a mathematical comparison 
between the techniques is what we looked for and what we found. 

Classical (polynomial) complexity bounds cannot be used, as the problem 
we are dealing with is (co-)NP-complete. Fortunately, polynomial simulations 
provide an elegant way of dealing with this (see e.g. 0 )- We say that proof 
system A polynomially simulates proof system B if for every formula (j) the size 
of the proof of (j) in system A is smaller than a polynomial applied to the size 
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of the proof of (j) in system B. Of course, if the polynomial is more than linear, 
proofs in system A may still be substantially longer than proofs in system B, 
but at least the proofs in A are never exponentially longer. It is self evident 
that for practical applications it is important that the order of the polynomial is 
low. If it can be shown that for some formulas in B the proofs are exponentially 
longer than those in A we consider A as a strictly better proof system than 
B. It has for instance been shown that ‘extended resolution’ is strictly better 
than resolution jl], being strictly better than Davis-Putnam resolution; for an 
extended overview of comparisons of systems based on resolution, Frege systems 
and Gentzen systems we refer to |S]. 

As a main result we explicitly construct a sequence of contradictory formulas 
that are easy for BDDs, but exponentially hard for resolution. The proof that 
they are indeed hard for resolution is based on results from |8I1| . 

Conversely we explicitly construct a sequence of contradictory formulas that 
are easy for any reasonable form of resolution, even only unit resolution, but are 
exponentially hard for BDDs. 

For proofs we refer to the full version jS] of this paper. 



2 Binary Decision Diagrams 

An Ordered Binary Decision Diagram (OBDD) is a Directed Acyclic Graph 
(DAG) where each node is labeled by a proposition letter from V, except for 
nodes that are labeled by 0 and 1. From every node labeled by a proposition 
letter, there are two outgoing edges, labeled ‘left’ and ‘right’, to nodes labeled 
by 0 or 1, or a proposition letter strictly higher in some fixed ordering < on V. 
The nodes labeled by 0 and 1 do not have outgoing edges. 

An OBDD compactly represents which valuations are valid, and which are 
not. Given a valuation cr and an OBDD B, the a walk of B is determined by 
starting at the root of the DAG, and iteratively following the left edge if a 
validates the label of the current node, and otherwise taking the right edge. If 
0 is reached by a cr-walk then B makes cr invalid, and if 1 is reached then B 
makes a valid. We say that an OBDD represents a formula if the formula and 
the OBDD validate exactly the same valuations. 

An OBDD is called reduced if the following two requirements are satisfied. 

— For no node do its left and right edge go to the same node. 

— There are no two nodes with the same label of which the left edges go to the 
same node, and the right edges go to the same node. 

The key property of reduced OBDDs states that for a fixed order < on V, every 
propositional formula (j) is uniquely represented by a reduced OBDD i? (</>), and 
(p and '0 are equivalent if and only if B(0) = B{tjj). 

As a consequence, a propositional formula 0 is a contradiction if and only if 
B{(j)) = 0, and it is a tautology if and only if B{(p) = 1. Hence by computing 
B((p) for any suitable order < we can establish whether 0 is a contradiction, or 
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0 is a tautology, or (p is satisfiable. We write pp{B{(f>)) for the number of internal 
nodes in 

The main ingredient for the computation of B((p) is the apply-opeTaiion: given 
the reduced OBBDs B{(p) and B{ip) for formulas 4> and ip and a binary connective 
o € {V, A, — >■, -O'} as parameters, the apply-operation computes B{(j)Oip). For 
the usual implementation of apply as described in |2I5| both time and space 
complexity are 0{PP{B{4>)) * =fp{B{tjj))). 

By the OBDD proof of a formula (p we mean the recursive computation of 
B(p) using the ap ply-operation as described above. An alternative approach 
based on rewriting for computing reduced OBDDs has been given in mg. 

3 Resolution 

Contrary to the BDD technique, resolution is applied to formulas in conjunctive 
normal form (CNF), i.e. formulas of the form 

A V 

iei jeJi 

where I and Ji are finite index sets and Uj is a literal, i.e. a formula of the 
form p or ~<p for a proposition letter p. Each sub- formula \/ j^j. hj is called a 
clause. As A and V are associative, commutative and idempotent it is allowed 
and convenient to view clauses as sets of literals and CNFs as sets of clauses. 

The resolution rule can be formulated by: 

{p, ?!,..., Zn} ) • ■ • ) ^ri' } 

{Zl, . . . , In, li, ■ ■ ■ , 

where p is a proposition letter and li, Z' are literals. A resolution proof of a 
set of clauses E is a sequence of clauses where the last clause is empty and 
each clause in the sequence is either taken from F, or matches the conclusion of 
the resolution rule, where both premises occur earlier in the sequence. Such a 
resolution sequence ending in the empty clause is called a resolution refutation, 
and proves that the conjunction of the set of clauses is a contradiction. 

In case one of the clauses involved is a single literal Z, by this resolution rule all 
occurrences of the negation of Z in all other clauses may be removed. Moreover, 
all other clauses containing Z then may be ignored. Eliminating all occurrences 
of Z and its negation in this way is called unit resolution. All practical resolution 
proof search systems start with doing unit resolution as long as possible. 

In order to apply resolution on arbitrary formulas, these formulas must first 
be translated to CNF. This can be done in linear time maintaining satisfiability 
using the Tseitin transformation [S]. A disadvantage of this transformation is 
the introduction of new variables, but without doing so transformation to CNF 
may be exponential. 

The Tseitin transformation works as follows. Given a formula p. Every sub- 
formula p of p not being a proposition letter is assigned a new letter p,^. Now 
the Tseitin transformation of p consists of 
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~ the single literal 

— the conjunctive normal form of -O- OPV' 2 ) for every subterm -ip of (j> 
of the shape pj = 'ipi o 1 P 2 for a binary operator o; 

— the conjunctive normal form of p^ -f-)- ~>p^^ for every subterm ^ of </> of the 
shape Ip = -iipi . 

Here p^. is identified with -pi in case pi is a proposition letter, for i = 1,2. It 
is easy to see that this set of clauses is satisfiable if and only if p is satisfiable. 
Moreover, every clause consists of at most three literals, and the number of 
clauses is linear in the size of the original formula p. 

By a resolution proof for an arbitrary formula we mean a resolution proof 
after the Tseitin transformation has been applied. 

4 The Main Result 

First we construct formulas that are hard for OBDD proofs but easy for resolu- 
tion. 

For n a positive integer and Pij distinct variables we define 

n n n n 

c'i?„ = (A(Vpb))A(A(Vpb))- 

i—l i = l i — 1 i—'i 

Imagine the variables in a matrix according to the indexes, then CRn states 
that in every column and in every row of the matrix at least one variable is true. 

For every order < on P it turns out that ppB{CRn) = 12(1.63"). As a conse- 
quence we arrive the same lower bound for any OBDD proof of the contradictory 
formula pA (-■pA CRn) since computation of B{ CRn) is part of this OBDD proof. 

Conversely it is not difficult to prove that applying only unit resolution on 
the Tseitin transformation of this formula yields a refutation in a number of 
steps linear in the size of the formula. Hence: 

Theorem 1 For the contradictory formulas pA (~'pA CRp of size 0{P) (i > 0) 
yielding a refutation in 0(P) steps using only unit resolution, every OBDD proof 
has time and space complexity 17(1.63*). 

Next we construct formulas that are easy for OBDD proofs but hard for 
resolution. 

For a string S = pi,p 2 ,ps, . . . ,Pn of proposition letters, where letters are 
allowed to occur more than once, we write 

[S] = Pi eA (P2 O (P3 • • • (Pn-1 ^ Pn)) ’ ’ •)• 

It is not difficult to see that [S'] is a tautology if and only if all letters occur an 
even number of times in S. 

Since all subformulas of a formula composed only of O, -■ and proposition 
letters turn out to have a linear size reduced OBDD, any OBDD proof of such 
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a formula is polynomial. More precisely, the complexity of the OBDD proof of 
is 0(|5p). 

We now give a construction of strings Sn in which all letters occur exactly 
twice by which is a contradiction, and for which every resolution proof of 

-n[Sn] is very long. 

For a string S and a label i we write lab(S', i) for the string obtained from S 
by replacing every symbol p by a fresh symbol pi. For a string S of length n * 2" 
we write ins(n, S) for the string obtained from S by inserting the symbol i after 
the {i * n)-th symbol for z = 1, 2, . . . , n. We define 

Si = 1, 1, and 

S'„+i = ins(n, lab(S'„, 0)), ins(n, lab(5„, 1)), 
for n > 0. For instance, we have 



5i 





S2 = 

>53 = 100,10,1, loo,2o,2, lio,lo,3, lio,2o,4, loi,li,l, loi,2i,2, ln,li,3, ln,2i,4. 



Clearly Sn is a string of length n * 2" over n * 2"“^ symbols each occurring 
exactly twice. The string Sn is constructed to consist of 2" consecutive groups 
of n symbols; in the examples Si, S 2 and S 3 above these groups are under-braced. 

Using results from mm it turns out that every resolution proof of =[5'„] 
contains 2^^^ resolution steps. In order to be able to formulate this result 
without double exponentiation define for every i the formula cj)i to be =[,S'„], 
where n is the smallest number satisfying i < ^. Hence: 



Theorem 2 For the contradictory formulas 4>i of size 6>(zlog^z) (i > 0) every 
OBDD proof has time and space complexity 0(z^ log'll), and every resolution 
proof requires 2^^*^ resolution steps. 



References 

1 . Ben-Sasson, E., and Wigderson, A. Short proofs are narrow - resolution made 
simple. In Proceedings of the 31st Annual ACM Symposium on Theory of Com- 
puting (1999), pp. 517-526. 

2. Bryant, R. E. Graph-based algorithms for boolean function manipulation. IEEE 
Transactions on Computers C-35, 8 (1986), 677-691. 

3. Groote, J. F., and Zantema, H. Resolution and binary decision diagrams 
cannot simulate each other polynomially. Journal of Discrete Applied Mathematics 
(2001). To appear. 

4. Haken, a. The intractability of resolution. Theoretical Computer Science 39 
(1985), 297-308. 

5. Meinel, G., and Theobald, T. Algorithms and Data Structures in VLSI Design: 
OBDD — Foundations and Applications. Springer, 1998. 



38 



J.F. Groote and H. Zantema 



6. Tseitin, G. On the complexity of derivation in propositional calculus. In Studies 
in Constructive Mathematics and Mathematical Logic, part 2 (1968), pp. 115-125. 
Reprinted in J. Siekmann and G. Wrightson (editors), dwtomotion of reasoning vol. 
2, pp. 466-483., Springer- Verlag Berlin, 1983. 

7. Uribe, T. E., and Stickel, M. E. Ordered binary decision diagrams and the 
Davis-Putnam procedure. In First eonference on Constraints in Computational 
Logic (1994), J.-P. Jouannaud, Ed., vol. 845 of Lecture Notes in Computer Science, 
Springer, pp. 34-49. 

8. Urquhart, a. Hard examples for resolution. Journal of the ACM 34, 1 (1987), 
209-219. 

9. Urquhart, A. The complexity of propositional proofs. The Bulletin of Symbolic 
Logic 1, 4 (1995), 425-467. 

10. Zantema, H., and van de Pol, J. C. A rewriting approach to binary decision 
diagrams. Journal of Logic and Algebraic Programming (2001). To appear. 




On Expressive and Model Checking Power of 
Propositional Program Logics 



Nikolai V. Shilov^’^ and Kwang Yi^ 

^ Korean Advanced Institute of Science and Technology, Taejon 305-701, 
Kusong-dong Yusong-gu 373-1, Korea (Republic of Korea), 
{shilov, kwangl@ropas.kaist.ac.kr 
^ A. P. Ershov Institute of Informatics Systems 
Russian Academy of Sciences, Siberian Branch 
6, Lavrent’ev ave., 630090, Novosibirsk, Russia 
shilovOiis . nsk . su 



Abstract. We examine when a model checker for a propositional pro- 
gram logic can be used for checking another propositional program logic 
in spite of lack of expressive power of the first logic. We prove that (1) 
a branching time Computation Tree Logic CTL, (2) the propositional 
/r-Calculus of D. Kozen /iC, and (3) the second-order propositional pro- 
gram logic 2M of C. Stirling enjoy the equal model checking power in 
spite of difference in their expressive powers CTL < /iC < 2M: every 
listed logic has a formula such that every model checker for this partic- 
ular formula for models in a class closed w.r.t. finite models, Cartesian 
products and power-sets can be reused for checking all formulae of these 
logics in all models in this class. We also suggest a new second-order 
propositional program logic SOEPDL and demonstrate that this logic is 
more expressive than 2M, is as expressive as the Second order Logic of 
monadic Successors of M. Rabin (S(n)S-Logic), but still enjoys equal 
model checking power with CTL, /rC and 2M (in the same settings as 
above) . 



1 CTL and fiC vs. Second-Order Logics 

The propositional /x-Calculus of D. Kozen (fiC) [10111] is a powerful proposi- 
tional program logic with fixpoints. In particular, a very popular with model 
checking community state-based temporal Computation Tree Logic (CTL) |3 
SEI is interpretable in /iC. It is almost a folklore that CTL is less expressive 
than fj,C. Nevertheless, expressibility problem rises every time when a particular 
property is concerned: whether this property can be expressed in CTL, in fj,C, 
or both logics are inadequate. 

For example, paper PP reports a progress in experiments with symbolic data 
representation by means of Binary Decision Diagrams (BDD) for solving some 
board games. In this research positions and moves are represented by BDD, 
an existence of winning strategy is expressed as a simple fj,C formula. Then a 
new model checking tool for a fragment of /rC and finite models presented by 
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BDDs has been applied. A natural question rises: why these experiments have 
exploited a new symbolic model checking tool instead of utilizing a very popular 
and reliable symbolic model checker for CTL? A natural move for exploiting 
a model checker of this kind for solving board games is to try to express an 
existence of winning strategy in finite games in terms of CTL formulae and then 
to experiment with these formulae, games presented by BDDs and the model 
checker. But this move is doomed to fail as follows from the game-theoretic 
arguments below. 

There are different formalisms for games. We would like the following: a 
game (of two plays A and B) (with terminal positions) is tuple {Pa, Pb, Ma, 
Mb,Wa,Wb), where 

— PaC\ Pb = ^ are nonempty sets of positions, 

— MaC {Pa \{WaUWb))x{PaUPb),MbC {Pb \{WaUWb))x {Pa U Pb) 
are moves of A and B respectively, 

— Wa, Wb C {Pa U Pb) are sets of winning positions for A and B. 

The game is said to be finite iff Pa and Pb are finite. A session of the game is 
a maximal sequence of positions sq, ...Sn, ■■■ such that (si,Si+i) G {MaA Mb) 
for all consequentive positions Si,Si+i G (sq, ...Sn, ^ player C € {A,B} 

wins a session iff the session finishes in Fq- A strategy of a player is a subset of 
the player’s possible moves. A winning strategy for a player is a strategy of the 
player which always leads to the player’s win: the player wins every session in 
which he/she implements this strategy instead of all moves. 

Proposition 1. 

1. No CTL formula can express existence of winning strategies infinite games. 

2. p.C formula p, x. {Pa V {Ma)x\/ {(MB)trueA [Mb]x)) expresses existence of 
winning strategies for player A against B in games with terminal positions. 

Proof. We would like to prove the first part only. We can consider CTL for- 
mulae without constructions AG, AF, EG, and EF at all due to the following 
equivalences: 



AF(f> o A{trueU(f>) EGf) O -'AF(-i(()) 

EF()) o E(trueU^) AGf> o —'EF(“i(^) 

Let us define nesting for CTL formulae of this kind as follows: 
nest{true) = nest{false) = 0, 
nest{r) = 0 for every propositional variable r, 
nest{-<4>) = nest{4>), 

nest{4> Alp) = nest{(f> y if) = m.sx.{nest{(j)),nest{if)}, 
nest{A{(jAJ'ili)) = nest{F{(jAJ%f)) = max{nest((/>), nest(V')}, 
nest{A'K(j)) = nesf(EX(/)) = 1-1- nest{cj>). 

Then let us consider a game NEC (Fig.[T|), where A/B-Yme represents positions 
where a player A/B has moves, downward/ upward arrows represent moves of 
A/B, WaIWb represents a single winning position for A/B. Then {—kA) \=neg 
(j) {—Ib) \=neg holds for every CTL formula 4> and for all k,l > nest{(j)). 
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A : 
B : 



(-*- 1 ) 

>2 



(- 1 - 1 ) 



NEGi 

i-i) . . .(-1) 

>2... X 

i-i) . . .(-1) 

NEGi 



(0) 



Wb 

(0) 



Fig. 1. Model NEG and NEGi 



Hence for every formula of CTL there exists a non-positive number prior to 
which the formula is a boolean constant in the NEG. Let us also remark that 
no CTL formula can distinguish positions of a finite game NEGi (fig- HJ from 
correspondent positions of NEG. But A has a winning strategy in all even 
integers on H-line and in all odd integers on i?-line. Hence no CTL formula can 
express an existence of a winning strategy for a player A in positions of finite 
games NEGi for i > 0. Thus the proof of proposition [1] is over. 

Another evidence of fj,C expressive power comes from comparison with the 
Second-order logic of several monadic Successors of M. Rabin (S(n)S-Logic) [T^ 
USE!: both logics enjoy equal expressive power on infinite trees m- But in spite 
of this, fj.C fails to express some very natural properties discussed below. For 
resolving the problem with a deficit of expressive power of /iC, the second order 
propositional program logic 2M of C. Stirling m uses second order quantifiers 
V/3 over propositional variables and reachability modalities □/<> upon strongly 
connected components of models. 

Proposition 2. 

1. No fiC formula can express commutativeness of composition of action sym- 
bols in finite models. 

2. 2M formula \/p.(^{[a][b]p) o ([&][a]p)) expresses eommutativeness of eomposi- 
tion of aetion symbols a and b in models. 

But some other very natural and useful properties are still inexpressible in 
2M. For instance 2M can not express the weakest precondition for inverse actions 
as it is defined below. Assume that a propositional variable p is interpreted in 
a model by a set of states P, and an action symbol r is interpreted by a binary 
relation R on states. The weakest pre-condition for inverse of r with respect to 
a post-condition p in this model is the following state of states {t : V s.{{s,t) G 
R ^ s G P)}. We would like to suggest a another Second-Order Elementary 
Propositional Dynamic Logic (SOEPDL) for handling this phenomenon. A single 
difference between 2M and SOEPDL is interpretation of reachability modalities 
□ /O: in SOEPDL they means “for every/some state in the model”. 

Proposition 3. 

1. No 2M formula ean express in finite models the weakest pre-eonditions for 
inverse of action symbol with respect to propositional variable. 

2. SOEPDL formula 3q.{p[(a)q p) A q) expresses the weakest pre-eonditions 
for inverse of action symbol a with respect to propositional variable p in models. 
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2 Expressiveness vs. Model Checking 

Theorem 1. 

CTL < fj.C < 2M < SOEPDL where all expressibilities have linear complexity 
and all inexpressibilities can be justified in finite models. 

Proof. 

First, CTL < /iC since it is well known that CTL < p,C and, in accordance 
with proposition [H there is fiC formula, which is not equivalent to any CTL 
formula in finite models. 

Next, fj,C < 2M since {p.p-4>) o (Vp. (□(</) — >■ p) — >■ p)), {vp.f)) o (3p.(D(p — 
(f>) A p)), and, in accordance with proposition |2] there is 2M formula, which is 
not equivalent to any pC formula in finite models. 

Finally, 2M < SOEPDL since reachability modalities can be expressed in 
terms of PDL programs as □(/) O [(UaeActa)*]^i) and 0(j) -O- ((UaeActa)*)^, and, 
in accordance with proposition [3] there is SOEPDL formula, which is not equiv- 
alent to any 2M formula in finite models. 

Thus the proof of the theorem [I] is over. 

An “internal” characteristic of the expressive power of SOEPDL in terms of 
other propositional program logics correlates with an “external” one: we demon- 
strate that SOEPDL is as expressive as Second Order Logic of n Monadic Succes- 
sors of M. Rabin (S(n)S-Logic) [1211312] . We would not like to give a complete 
definition of S(n)S -Logic, but would like to point out that we use action symbols 
as symbols of monadic functions (i.e., “successors”) and exploit functional mod- 
els, where action symbols are interpreted as total monadic functions. In these 
settings functional models are just special kind of SOEPDL models. Boolean 
values of formulae of S(n)S -Logic in functional models depend on values of free 
individual variables only. Thus boolean values of formulae of S(n)S-Logic with 
a single (at most) free individual variable depend on values of this single variable. 
In this setting semantics of formulae of S(n)S-Logic with a single (at most) free 
first order variable is a state-based semantics as well as semantics of SOEPDL 
and it is possible to compare semantics of formulae of S(n)S -Logic of this kind 
and SOEPDL formulae in terms of equivalence. 

Theorem 2. Expressive powers of SOEPDL and S{n)S-Logic are linear time 
equivalent in the following sense: 

— for every formula of S{n)S-Logic with a single (at most) free first-order 
variable it is possible construct in linear time an equivalent in all functional 
models formula of SOEPDL; 

— for every formula of SOEPDL it is possible construct in linear time an equiv- 
alent in all functional models formula of S{n)S -Logic with a single (at most) 
free first-order variable. 

Expressiveness is a particular dimension where we can compare a power of 
program logics. Another possible dimension is model checking power. Let us 
discuss it below. Global (model) checking consists in a calculation of the set 
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- {s,S^, ...S'j, (V’ivV’ 2 )) -S' (s, S^, ...S^,ipi) for every i G {1,2}; 

- (s, Sx, ■■■Sz, (j^V’)) -S' (fi Sx, ■■■Sz,'tp) for every t such that (s,t) G /(a); 

- (s, Sx, ■■■Sz, i%^)) -S' (t, Sx, ■■■Sz,’>p) for every t in M; 

- (s, Sx, ■■■Sy, ...Sz,(^y-'^)) -S' (s, Sx, ■■■S, ...Sz,ip) for every S C D. 



Fig. 2. Moves of Falsifier/ Verifier 



of all states of an input model where an input formula is valid. Local (model) 
checking is checking an input formula in an input state of an input model. If LG 
is a logic and MD is a class of models, then a model checker for LGxMD is a 
program (algorithm) which can check all LG formulae in all MD models. Assume 
LG' is a propositional program logic and MG' be a model checker for LG'xMD. 
Assume we would like to check formulae of another propositional program logic 
LG" in MD models. A first move is to try to reuse MG', i.e., to force MG' to do 
this job instead of expensive and risky design, implementation and validation of 
a new model checker MG" for LG"xMD. If LG" < LG' then the work is done. 
The question is: when LG" ^LG', is it still possible to reuse MG' for LG"xMD? 
In particular, whether a model checker of GTL formulae in finite models can be 
utilized for solving board games in spite of lack of expressive power of GTL? 

Let ^ be SOEPDL formula. Without loss of generality we can assume that 
variables bounded by different quantifiers are different (so there are no name 
collisions). Moreover we can assume that negations in the formula are applied 
to propositional variables only since the following equivalences hold: 

(“'(“'<(>)) ^ 4 ^ 

(-'(</> A tp)) O ((-.</>) V (-.((a)(/))) O ([a](-.</>)) 

^ 0=l(-'(/')) (-.(3p.^)) O' (Vp.(-.(^)) 

Let X, ... z he a list of all bounded propositional variables in (p. A subformula 
of ^ is a formula, which is (syntactically) a part of <p- A subformula is said to 
be conjunctive iff it has one of the following forms: (p A ip, [a\(p, □(/> or ^p.(p. A 
subformula is said to be disjunctive iff it has one of the following forms: (p\I ip, 
{a)(p, Ocp or 3p.(p. Propositional variables and their negations (and only they) 
are neither conjunctive nor disjunctive subformulae. Let M he a finite model 
with a domain D and an interpretation I . 

We are going to construct a Hintica-like finite game G{M,^) of two players 
Falsifier and Verifier. Positions in this game G{M,^) are tuples {s, Sx, .■■Sz,ip) 
where s G D is a current state, Sx, ...Sz C D are current interpretations for x, 
... y, and ip is a verified subformula of Falsifier/ Verifier has moves of 4 kinds 

(Fig. [2) related conjunctive/disjunctive subformulae respectively, and wins in 
positions of 6 kinds (Fig. |3)- Intuitively: Verifier is trying to validate a formula 
in a state while a rival Falsifier is trying to falsify the formula in a state. 

The following is easy to prove by induction on formula structure. 

Proposition 4. For every finite model M = (D,I) and every SOEPDL formula 
^ there exists a finite game G{M,ff) of two players Falsifier and Verifier such 
that the following holds for every state s G D and every subformula cp of 
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_ / C O false \ 

Dx, •••Oz, 

- (s, Sx, ■■■Sz,p), where p is a free propositional variable and s^I{p), 

- (s, Sx, ■■■Sz, ~'p), where p is a free propositional variable and s^I{p), 

- {s,Sx,-Sz, iff (s,t) ^I{a) for every t; 

- {s,Sx,-Sy,...Sz,y), where s^Sy, 

- {s, Sx, ■■■Sy, ...Sz,-^y), where SjSy. 



Fig. 3. Winning positions of Falsifier/ Verifier 



Verifier has a winning strategy against Falsifier in a position {s,I{x), ...I{z),4>) 
iff s \=M 4> (where x,...z is a list of all bounded variables off,). The game can 
be constructed in time x d x /), where d is amount of states and f is 

formula size. 

It immediately implies the following sufficient 

Criterion Let L' be a program logic and MC be a model checker for this logic 
L' in finite models which can check an existence of a winning strategy for a 
player against a counterpart in positions of finite games with time complexity 
T(m), where m is an overall game size. Let L" be another logic which is ex- 
pressively equivalent to a fragment of SOEPDL and C{f) and S{f) be time and 
space complexity of a translation L" formulae into SOEPDL formulae, where 
f is a formula size. Then MC can be reused for checking L" formulae in fi- 
nite models and upper time bound for model checking L" in finite models is 
max{C{f), xdx S{f)))}, where d is amount of states in the model. 

A consequence of the above criterion, proposition [T] and theorem [T] is the 
following 

Theorem 3. Let MC be a model checker which implements linear in an overall 
model size model checking algorithm for the following formula fi x. (p V {a)x V 
{{b)true A [6]a;)) of fiC in finite models. MC can be reused for checking all 
formulae of SOEPDL, 2M, and p,C in finite models with upper time bound 
exp{d X f), where d is amount of states in a model and f is formula size. 

We would like to remark that a formula p, x. (p V {a)x V {{b)true A [&]x)) from 
the theorem above can be checked in finite models in linear time |0]. 

We would like to generalize the above theorem |3] as follows below. A class 
of models MD is closed with respect to Cartesian products iff for all models M' 
and M” in MD, every model M with Dm = Dm' x Dm" is in MD also. A class 
of models MD is closed with respect to power-sets iff for every model M' in MD, 
every model M with Dm = P{Dm') is in MD also. Due to space limitations we 
would like to present the following theorem without proof. 

Theorem 4. Let MD be a class of models which contains all finite models and 
is closed with respect to Cartesian products and power-sets. Let MC be a model 
checker which can check (at least) the following formula (EFp) of CTL in models 
in MD. Then MC can be reused for checking all formulae of SOEPDL, 2M, 
pC and CTL in models in MD. 
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3 Conclusion 

We began this research from a particular problem whether a model checker 
for CTL formulae in finite models can be used for solving board games. Now 
we content our curiosity: in principle yes it is (theorem |4|, in spite of lack of 
expressive power (proposition [I]) . Theoretical method suggested for it is very 
simple from algebraic viewpoint, since it exploits Cartesian products and power 
set operation. But it is too expensive in computation complexity and impractical 
due to double exponential blow up of a model (power set operation is used twice). 

In general, in spite of algorithmical inefficiency of presented results, contri- 
bution of this paper is two- folds. First we study expressive and model checking 
power of the classical propositional logic or a basic propositional modal logic K 
mm, extended by transitive closure (CTL), fixpoints (/iC), and second-order 
monadic quantification (2M and SOEPDL). We consider this study as a propo- 
sitional counterpart of a popular research topic in descriptive complexity, where 
expressive power and finite spectra are examining for First-Order Logic, extended 
by transitive closure (FOL-I-TC), fixpoints (FOL-I-FP), and second-order quan- 
tification (SOL) [H]. 

Next contribution consists in model checkers reuse. Let us discuss it with 
some details in the next paragraph. Assume we have a reliable model checker 
MC for CTL in finite models, but we would like to check in finite models formulae 
of more powerful combined logic (CTL-I-PDL) extended by program intersection 
n (it is essential for representation and reasoning about distributed knowledge 
in logic of knowledge i)- This extended logic can not be expressed neither in 
CTL nor in ^C (due to presence of program intersection), but in SOEPDL only 
as follows: 'ip.{[a 0 (i]p O {[a]p A [(d]p))- Does it imply a necessity to implement 
a new model checker in stead of MC? Or does it imply that code revision and 
patching of MC are inevitable? — Not at all, as it follows from equal model 
checking power of CTL and SOEPDL! One can try to encode extensions in 
models instead of risky implementation and patching. If it can be done in feasible 
time and space in terms of MC’s input language for models, then just implement 
it as a preprocessor for MC, and reuse MC for extended logic. In particular, this 
approach is valid for (CTL-fPDL) extended by program intersection O, since 
an encoding in this particular case is linear in time and space. But in general, 
better analysis when model checkers for CTL and /iC in finite models can be 
reused for model checking other logics in finite models without loss of efficiency 
is a research topic for a perspective. 

Finally we would like to remark that close connections between model check- 
ing for /xC and special games have been extensively examined unnznHi. In 
particular, m has defined infinite model checking games and established an 
equivalence of local model checking to an existence of winning strategies. Then 
m has defined finite fixed point games and characterized indistinguishability 
of processes by means of formulae with bounded amounts of modalities and 
fixpoints in terms of winning strategies with bounded amounts of moves. Paper 
E! has exploited model-checking games for practical efficient local model check- 
ing. Paper m has defined also logic 2M, corresponding games and established 
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indistinguishability of states by means of formulae with bounded amounts of 
modalities and quantifiers in terms of winning strategies with bounded amounts 
of moves. So it is possible to summarize that I16I17I18I have exploited infinite 
games for local model checking /rC in infinite models. In contrast, we exploit 
games with terminal positions (basically, finite games) for forcing model checkers 
for CTL to check more expressive logics /xC, 2M, and SOEPDL. 
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Abstract. We consider first-order Dynamic Logic (DL) with non-rigid 
functions, which can be used to model certain features of programming 
languages such as array variables and object attributes. We extend this 
logic by introducing, for each non-rigid function symbol /, a new function 
symbol that after program execution refers to the old value of / 

before program execution. We show that DL formulas with @pre can be 
transformed into equivalent formulas without @pre. We briefly describe 
the motivation for this extension coming from a related concept in the 
Object Constraint Language (OCL). 



1 Introduction 

Since the Unified Modeling Language (UML) [TT] has been adopted as a standard 
of the Object Management Group (OMG) in 1997, many efforts have been made 
to underpin the UML — and the Object Gonstraint Language (OGL), which 
is an integral part of the UML, — with a formal semantics. Most approaches 
are based on providing a translation of UML/OGL into a language with a well- 
understood semantics, e.g., BOTL and the Larch Shared Language (LSL) [6]. 

Within the KeY project [1], we follow the same line, translating UML/OGL 
into Dynamic Logic (DL)f| This choice is motivated by the fact that DL can 
cope with both the dynamic concepts of UML/OGL and real world programming 
languages used to implement UML models (e.g. Java Gard [4|). 

The OGL allows a UML model to be enriched with additional constraints, 
e.g., invariants for UML classes, pre-/post-conditions for operations, guards for 
transitions in state-transition diagrams, etc. Although, at first glance, OGL is 
similar to an ordinary first-order language, closer inspection reveals some unusual 
concepts. The @pre operator is among them. In OGL, this unary operator is 
applicable to attributes, associations, and side-effect-free operations (these are 
called “properties” in the OGL context [m p. 7-llff]). The @pre operator can 
only be used in post-conditions of UML operations. A property prop followed by 
@pre in the post-condition of an operation m() evaluates to the value of prop 
before the execution of m(). 

^ More information on the KeY project can be found at il2www.ira.uka.de/~key. 
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Dynamic Logic |7|8| 9|10 | can be seen as an extension of Hoare logic • It is 
a first-order modal logic with modalities [p] and (p) for every program p. The 
models used to define the semantics of DL consist of the possible program states. 
The formula [p](/> expresses that 4> holds in all final states of p when started in 
the current state, and {p)4> expresses that (j) holds in at least one of them. In 
versions of DL with a non-deterministic programming language there can be 
several such final states. For deterministic programs there is exactly one final 
state (if p terminates) or there is no final state (if p does not terminate). In that 
case, the formula t {p)'4’ is valid if, for every state s satisfying pre-condition (j), 
a run of the program p starting in s terminates, and in the terminating state the 
post-condition ij) holds. The formula (j) — > [pji/' expresses the same, except that 
termination of p is not required, i.e., '0 must only hold if p terminates. Thus, 
(j) — >■ [pj'i/' is similar to the Hoare triple {(f>}p{fj}. 

Here, we consider a version of first-order DL with non-rigid functions, i.e., 
functions whose interpretation can differ from state to state. Non-rigid functions 
can be used to model features of real-world programming languages such as array 
variables and object attributes. 

Moreover, to ease the translation of OCL into DL, we extend DL by introduc- 
ing, for each non-rigid function symbol /, a new corresponding function symbol 
j@pre specially tailored semantics. The new symbol refers in the 

final state of a program execution to the value of the corresponding symbol / in 
the initial state of the program execution. This allows to easily express the rela- 
tion between the initial and the final state. For example, [p](c = c®^”'®) expresses 
that the interpretation of the constant c is not changed by the program p. 

In Section [2, we briefly introduce DL with non-rigid functions. In Section E] 
we add function symbols with @pre to DL and formally give their semantics. 
Finally, in Section S] we present two transformations from DL with @pre into 
DL without @pre. 

The main contribution of this paper is to show that DL formulas containing 
the new function symbols with @pre can be transformed into equivalent formulas 
without them. An extended version of this paper containing additional material, 
including examples and proofs, is available |3]. 

2 Dynamic Logic with Non-rigid Functions 

Although non-rigid functions are mostly ignored in the literature, the more spe- 
cific concept of array assignments has been investigated [zm. In both papers 
their semantics is handled by adding to each state valuations of second-order 
array variables. We introduce, instead, non-rigid function symbols. This shift of 
attention comes naturally when we want to axiomatise the semantics of object- 
oriented languages in DL. In this setting non-static attributes of a class are best 
modelled by non-rigid functions. 

Let E = Enr U Tlr be a signature, where Enr contains the non-rigid function 
symbols and Er contains the rigid function symbols and the predicate symbols, 
which are all rigid {E^ always contains the equality relation =). The set Term{E) 
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of terms and the set Atom{E) of atomic formulas are built as usual from E and 
an infinite set Var of object variables. A term is called non-rigid if (a) it is a 
variable or (b) its leading function symbol is in E^r- 

The programs in our DL are (deterministic) while programs with a gener- 
alised assignment command, reflecting the presence of non-rigid terms. 

Definition 1. The sets FmlDL{E) of DL-formulas and Progori^) 

grams are simultaneously defined as the minimal sets satisfying the following 

conditions: 

— Atom{E) C FmloLiE). 

— are in FuiloLiE), then so are -'fii, <f>\/\ 4 > 2 , <f> 2 , 

<fi ^ 4>2, and \/x4>i and 3x(j)i for all x € Var. 

— If 4> is in FmlDL{E) and p is in ProgDL{E) , then {p)(j> and [p]4> are in 
FmlDL(E) (in that case, (f> is called the scope of (p) resp. [p]). 

— If t is a non-rigid term and s is a term, then t := s is in ProgDL(E) . 

~ If P 11 P 2 are in ProgoriE), then so is their sequential composition pi;p 2 - 

— If Ip is a quantifier-free first-order formula andp,q are in ProgDL(E), then 
if ^/>thenpelsegfi and while f/) do pod are in ProgoriE) . 

Note, that all terms can occur within programs. In particular, we do not 
make any distinction between program variables and object variables. 

In the following, we often do not differentiate between the modalities (p) 
and [p] , and we use (p} to denote that a modality may be of either form. 

The Kripke structures used to evaluate formulas from FmloLiE) and pro- 
grams from ProgDL{E) are called DL-Kripke structures. The set of states of 
a DL-Kripke structure K. is obtained as follows: Let Aq be a fixed first-order 
structure for the rigid signature E^., and let A denote the universe of Aq. An 
n-ary function symbol f £ E^ is interpreted as a function /-^° : A” — >■ A and 
every n-ary relation symbol r £ Er is interpreted as a set C A" of n-tuples. 
A variable assignment is a function u : Var -£■ A. We use u[x/b] (where b £ A 
and x € Var) to denote the variable assignment such that u[x /b]{y) = b ii x = y 
and u[x/b]{y) = u{y) otherwise; moreover, if K is a set of variables, then u\v 
denotes the restriction of u to V. The set S of all states of 1C consists of all 
pairs (A, u), where u is a variable assignment and A is a first-order structure for 
the signature E, whose reduction to Er, denoted by A\s^j coincides with Aq. 
We are now ready to define for each program p its interpretation p(p), which is a 
relation on S (accessibility relation). Simultaneously, we define when a formula 
(p is true in a state (A, u), denoted by (A, u) |= <p. 

Definition 2. The interpretation p(p) of programs p and the relation ^ be- 
tween S and FmloL{E) are simultaneously defined as follows: 

1. (A, m) \= 4> is defined as usual in classical logic if (p is an atomic formula or 
its principal logical operator is one of the classical operators A, V, — >■, ££, 
- 1 , or one of the quantifiers V, 3. Also, the evaluation fiAA qJ terms t is 
defined as usual. 

2. (A, m) ^ {p)(p iff there is a pair {{A, u) , {B , w)) G p(p) with (B,w) ^ <p. 
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3. {A, u) ^ [p]4> iff {B, w) \= 4> for all pairs {{A, u), (B, w)) of states in p{p). 

4- If X is a variable, then p{x := s) = {{{A,u),{A,u[x/ s'^'^'’^'^])) \ {A,u) G S'}. 
5. If t = f{ti, . . . ,tn) is a non-rigid term, then p{t := s) consists of all pairs 
{{A, u) , {B , u)) such that B coincides with A except for the interpretation 
of f, which is given by 



6. p{pi;p 2 ) consists of all pairs {{A, u) , (C , w)) such that ((A, u) , {B , v)) G p(pi) 
and ((B,v),(C,w)) G p(p 2 ). 

7. p( while do pod) and p(if ■i/jthenpelsegfi) are defined as usual, e.g. m- 

Definition 3. A DL-Kripke structure 1C is a model of (j), denoted by K,\= cf, iff 
{A,u) 1= 4> for all states {A,u) of 1C. A formula (f is universally valid, denoted 
by 1= (f>, iff every DL-Kripke structure is a model of 4>. A formula (f> is satisfiable 
iff there are a structure 1C and a state {A,u) of K. such that (A,u) |= (j). 

The particular choice of programs in ProgohiAl) (Def. 0 is rather arbitrary. 
The results being proved in this paper hold true for all choices of ProgoLiH) — 
including non-deterministic programming languages — , as long as Lemma [T] is 
guaranteed to hold. This lemma states that the effect of a program p is restricted 
to and only depends on the symbols occurring in p. 

Lemma 1. Let 1C = (S, p) be a DL-Kripke structure over a signature S , let p 
be a program, let be the set of all variables occurring in p, and let be the 
set of all non-rigid function symbols occurring in p. 

1. The program p only changes variables in ; i.e., if x ^ then u{x) = w{x) 
for all {{A,u),{B,w)) G p{p). 

2. The program p only changes non-rigid symbols in that is, if f ^ 

then /•^ = for all {{A,u), (B,w)) G p{p). 

3. The relation pfp) is closed under changing variables not in in the sense 
that, if {{A, u), {B, w)) G p{p) and u' \yp = Mp/p, then {{A, u'), {B, w')) G p{p) 
for all w' with wfyp = w\yp and w' \(yar\VP) = u' \{Var\VP)- 

4- The relation p{p) is closed under changing the interpretation of non-rigid 
symbols not in i.e., if {{A, u) , {B , w)) € p{p) and A'jj;p^ = then 

for all B' with B'jjjp^ — Bjj;p^ and we also have 



3 Extended Dynamic Logic with @pre 

The Dynamic Logic defined in the previous section is suitable for the translation 
of OCL expressions that do not contain OCL’s @pre operator. The detailed 
description of such a translation is outside the scope of this paper. It is important 
to note, however, that OCL properties (to which the @pre operator may be 
applied) are mapped into non-rigid function symbols in DL. That gives rise 




{{A',u), (B',w)) G p{p). 
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to the question of how a DL translation can be defined for OCL expressions 
containing the @pre operator. 

The solution is to extend Dynamic Logic by adding to signatures for each non- 
rigid symbol / a new non-rigid symbol The new symbols have a special 

semantics that captures exactly the meaning of @pre in OCL: the interpretation 
of in the final state of a program execution is the same as that of / in the 

initial state of the program execution. Because of their special purpose, function 
symbols with @pre are not allowed to occur within programs. 

Definition 4. Let S = Sr ^ Snr be a signature. Then, the set of non-rigid 
function symbols of the extended signature S® = U S®r S®r = ^nr U Spre 
where Spr, = | / S 

The set Fmli)j^a(S) of extended DL formulas is defined as the set of DL 
formulas (Def.\^ over the extended signature S® , except that programs must not 
contain any of the new symbols from Spre, i-S-, ProgDi,<a{S) = ProgoLiS). 

The semantics of formulas in Fmljyi^m (S) is defined using DL-Kripke struc- 
tures over the extended signature S®. 

Definition 5. Let S = Sr U Snr be a signature, and let K. = {S, p) be a DL- 
Kripke structure over S that is built using some first-order structure Aq over Sr- 

Then, the DL®-Kripke structure IC® = {S®,p®) is defined as follows: 
S® consists of all states {A, u) such that A is a structure for the extended sig- 
nature S® = Srid Snr U Spre with A\Sr = Aq, and u is a variable assignment. 
The accessibility relation p® is obtained from the accessibility relation p of 1C for 
all programs p by: {{A,u), {B,w)) G p®{p) iff 

1. e p(p) and 

2. = fA all f®P^^ G Spre. 

The relation ^ between states of K,® and formulas in Fmljji^<m{S) is defined 
in the same way as the relation |= between states oflC and formulas in FmloL^S) 
(Def\^ 1.-3.), except that p® is used instead of p. 

It usually only makes sense to use function symbols f®P^~^ g S®r within the 
scope of some modality {p}, i.e., “after” the execution of some program p, be- 
cause the purpose of f®P^'^ is to refer to the value of / “before” executing p. 
Nevertheless, by definition, a symbol f®P^^^ g S®r may as well be used outside 
the scope of any modality, in which case its semantics is similar to that of a rigid 
function symbol. 

4 Transformations for Removing @pre from DL Formulas 

The fixed interpretation of functions symbols in Spre when occurring in the 
scope of a modality requires a special treatment by calculi for the extended DL. 
For example, the rule based on the equivalence of {p){q)4> and {p;q)4>, which 
is part of most calculi for DL, cannot be used anymore. It is not sound in 
case 4> contains a function symbol f®P^^ g Spre and the interpretation of the 
corresponding function symbol / is affected by the program p. 
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For practical reasons, however, we need a deductive calculus for the ex- 
tended DL. Our solution to this problem, which allows to check satisfiability 
resp. validity of extended DL formulas, is to implicitly define a calculus for 
extended DL by providing a transformation from the extended into the non- 
extended version of DL (as defined in Section m. That is, given a formula with 
occurrences of @pre, it is transformed into a formula without @pre, to which 
then a standard DL calculus can be applied. 

In the following, we define two transformations on formulas of extended DL 
that allow to remove function symbols with @pre that occur in the scope of a 
modality (occurrences of symbols with @pre that are not within the scope of a 
modality are harmless and do not have to be removed) . The first transformation 
(Sect. I4.2|l is simpler but has also only weaker logical properties than the second 
transformation (Sect.23|- 



4.1 Generalised Substitutions 

The two transformations we define in the following are based on smaller local 
transformations, which can be seen as a generalised substitution 'iplOrig / Subsij, 
where both Orig and Subst can be terms and function symbols. 

Definition 6. Let cj) G Fmljyi^a{S) be an extended DL formula over a signa- 
ture S = Sr US„r, let t,t' G Term{S®) be terms over the extended signature 
S® = SrU Snr U Spre; eind let /, /' G S® be function symbols. 

The generalised substitution (of terms) is defined as the result of 

replacing all those occurrences oft in by t' that (a) are neither within the 
scope of a modality [p] nor within a program p and (b) do not contain any 
variables bound by a quantifier within (j). 

The generalised substitution (of function symbols) 4>lf / f] is defined as the 
result of replacing all those occurrences of f in (j> by f that are neither within 
the scope of a modality (p) nor within a program p. 



Example 1. The result of applying |c/ci] to the formula r(c) A (c := c-l- l)r(c) 
is r(ci) A (c := c-l- l)r(c). Applying |s(a:)/3] to 3xs(a;) = 5 yields 3xs(a:) = 5. 



4.2 Transformation Introducing New Function Symbols 

The idea of the transformation T{ (the subscript f indicates that Tf introduces 
new function symbols) is to replace a function symbol J®?’'® by a new rigid 
function symbol f . 

Below, the transformation Tf is formally defined only on a fragment of ex- 
tended DL formulas, namely formulas of the form {p]4>. Moreover, r/ can only 
replace those occurrences of f®P"^^ that are not within the scope of a nested 
modality in [p^f). We discuss the extension of Tf to full extended DL at the end 
of this sub-section. 
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Definition 7. Let S = Snr be a signature, let p be a program over S, let 
(p € Fmljji^o^S) be an extended DL formula, and let f be a new rigid function 
symbol not occurring in We define 

T-f(M0) as yxi-.-yx^fixi,... ,Xn) = f{xi,... ,x^) A[p](plf®P'^^/fj 
where X\,. . . ,Xn are variables not occurring in {p]4>. 

The result of applying the transformation T{ is an extended DL formula in 
Fmljji^a{E'^ U Snr) where i?' = A'r U {/'}. 

Theorem 1. Using the notation from Definition^ the following holds: 

h Tf{{p](l^) (i-e-, Tf{[p](j)) is logically stronger than {pjp). 

iff ~^Tf{{p](t>) (i-e., {p](b is satisfiable iff Tf{{p](j)) is satisfiable) . 

The logical relationship between the original and the transformed formula is 
exactly the same as, for example, between a first-order formula and its skolemised 
version. In both cases we extend the signature and get a logically stronger for- 
mula which is satisfiable iff the original formula is satisfiable. 

The transformation Tf (as defined above) can be used as the basis for a 
transformation that is applicable to all extended DL formulas. The idea of this 
more general transformation is to first convert the original formula ip into an 
equivalent formula in negation normal form (NNF). The NNF property ensures 
that replacing in ipNNF a sub- formula ^ by a formula p' that (a) is logically 
stronger than and (b) satisfiability equivalent to (p yields a formula ip']\[pfp that 
has these two properties w.r.t. ipNNF and, thus, w.r.t. ip (see [ 3 ] for details). 

4.3 Transformation Introducing New Variables 

The second transformation Ty (the subscript v indicates that new variables are 
introduced) replaces terms of the form /®P’'®(ti, ... , t„) by new variables. Again, 
the transformation is formally defined only on a fragment of Fml jj i^a (S) . Now, 
we have the additional restriction that the terms ti,... ,tn must not contain 
variables that are quantified in the formula to be transformed. Again, we discuss 
the extension of Ty to full extended DL at the end of this sub-section. 

Definition 8. Let S = Sr D Snr be a signature, let (p S Fmljyi^m(S) be an ex- 
tended DL formula, let he a function symbol, let p be a program over S , and 

letti,... ,tn & Term{S®) be terms such that no ti contains a variable quantified 
in (p. Now, let y,xi,.. . ,Xn be variables not occurring in {p](p. We define 

Ty{{p)(p) as 3y3xi...3xnV= f{xi,... ,Xn) A 

\p) = U) A (plf^P'^^fti, . . . ,trP)/y\ 

Ty{[p](p) as VyVxi . . .Vx„y = /(a;i, . . . ,Xn) -)■ 

Theorem 2. Using the notation from Definition\^ the following holds: 



h {pU ^ ry{{p](p). 
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The relationship between the original and the result of the transformation 
is stronger for than for the transformation T{ presented in the previous sub- 
section. It does not change the signature and, indeed, leads to a logically equiva- 
lent formula (which is all one can wish for). Consequently, Ty can be recursively 
applied to sub-formulas of an extended DL formula. 

Unfortunately, the main restriction on the applicability of Ty, namely that 
the terms , . . . ,tn must not contain quantified variables, cannot be lifted easily 
without destroying soundness of the transformation. Thus, for example, Ty can- 
not be used to remove from the formula (p)Va; r(/®^''®(a:)). 

The problem of quantified variables can be tackled by shifting the quantifi- 
cations of variables in the post-state formula to the outside of the modality (p] 
(e.g., {p)'ix(f){x) becomes 'ix{p)4>{x)). In some cases, however, this technique re- 
quires the program p to be deterministic. To be more precise, when V is shifted 
over (p) or 3 is shifted over [p], the result is in general not an equivalent for- 
mula for non-deterministic programs p (see [3] for details). In the above example, 
(p)Va:r(/®^”'®(a:)) is transformed into Vx(p)r(/®P’’®(x)) (shift of quantification) 
and then into Vx3p3cci y = f{x\) A (p) x\ = x A r{y) (application of Ty). Assum- 
ing p is indeed deterministic, the latter formula is equivalent to the original. 
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Abstract. In many real-time applications, such as distributed logic con- 
trol systems, response time is crucial. The response is generated by com- 
putation of Boolean functions. In this paper event-driven method of re- 
computations is suggested to get rid of computation overheads and pro- 
vide the response in optimal time. New type of decision diagrams called 
Index Decision Diagrams (IDD for short) is introduced to facilitate such 
computations. Using IDD the computation of the function is performed 
in time, linear to the number of non-zero elements in the argument vector. 
Event-driven recomputation consists of two parts: online recomputation 
which is proven to have running time linear to the number of changed 
arguments, and precomputation which prepares the model for the former 
part in a fixed state of the arguments. 



1 Introduction 

This paper deals with the computational issues arisen in a class of real-time sys- 
tems. A big deal of such systems as discrete controllers in industrial automation, 
have always been relying on massive Boolean computations. In these systems a 
controller communicates with the controlled system (called plant) by means of 
signals, which relay values of sensors to inputs of the controller and values of 
the outputs to the actuators of the plant. The controller is a computing device, 
implementing a control algorithm. 

The control algorithm is usually represented in one of the programming lan- 
guages specific for this field, implementation of which is reduced to the real-time 
computation of a (huge) number of Boolean functions. 

The usual way of the computation is cyclic. First, the current status of the 
plant, which is indicated by sensors, is stored in an input buffer, then the whole 
control program (Boolean functions) is executed, while the values of inputs in 
the buffer remain unchanged, and in the last step the calculated outputs are 
transmitted to the actuators of the plant. Such a procedure, called scan repeats 
itself over and over again. The duration of the scan determines the response 
characteristic of controller. The shorter response is, the better the quality and 
reliability of the control are expected. 



D. Bj0rner, M. Broy, and A. Zamulin (Eds.): PSI 2001, LNCS 2244, pp. 55-|6^ 2001. 
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The latest trends in the development of control systems urgently require 
changes in these ’’cyclic” computations. We mention here two main reasons: 

1. The control systems become distributed. As a consequence the data are de- 
livered to/from controllers not directly, but via a network as events, i.e. mes- 
sages about changes of the inputs/outputs. The new being developed stan- 
dard for distributed controller design IEC61499, introduced in [3j, largerly 
relies upon the event-driven implementation. This requires updated methods 
of computations. 

2. The control algorithms themselves are getting more complicated. The super- 
visory control theory, introduced by Ramadge and Wonham [^, suggests to 
divide the controller onto two parts: the sequential controller which reflects 
the required processing cycle, and the supervisor, which observes the current 
situation and prevents the control system from getting to dangerous states. 
It is possible to build such supervisors automatically, given a formal model 
of a controlled plant and a formal description of the notion of ” danger” . The 
resulting supervisors, however, turn to be huge arrays of very complicated 
Boolean functions. Computation of supervisors is even more complicated, 
when the latter is placed to the distributed environment mentioned above. 

In this paper we attempt to suggest a way of computation corresponding to 
the new challenges. 

2 Re-evaluation versus Evaluation 

Binary Decision Diagram (BDD) is a directed acyclic graph (dag) with a sin- 
gle root, introduced in for Boolean function representation. Evaluation of a 
Boolean function / : {0, 1}” — )> {0, 1} is performed by a branching program with 
the structure of the BDD given an instance of input argument X G {0, 1}" in 
time 0(n) (for restricted BDD). This way of computation is also called start-over 
or full evaluation. 

In this paper we introduce the BDD derivative termed Index Decision Dia- 
gram (IDD) which computes f(X) in time linear to the ’’number of ones” in the 
vector X. Instead of dealing with the input vector represented as a Boolean vec- 
tor, it is more compact to use its compressed form of the ordered list of indexes 
A(A) of the elements equal to 1. For example, A((0000100001)) = (5,10). The 
IDD is a BDD modification intended to process the input represented this way. 

The IDD application can be beneficial for the computation if the input array 
is sparse, i.e. one value, for example zeros, predominate over the other (ones) 
in every input instance. The other application which we are going to show in 
this paper, is the event-driven re-evaluation of a Boolean function. As opposed 
to the evaluation, the re-evaluation finds f(Xnew) given the change A G {0,1}" 
to the input X^id such that = X^id © A. For example, Xom = (00010001), 
A = (01000001), and Xnew = (01010000). In many applications the change 
occurs just in a few bits of the input array at once, so A is very sparse Boolean 
array and the IDD application seems to be reasonable. 
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When the re-evaluation is applied to the event-driven systems it is assumed 
that the change A is induced by an event. We suggest to use some precomputa- 
tion, placed between events to prepare some auxiliary data which is used upon 
events to accelerate the on-line re-evaluation. It is important to minimize both 
parts, with the emphasis on the on-line part which is especially critical for the 
response characteristic of many discrete-event applications, such as logic con- 
trol, etc. Usually in such applications events occur relatively seldom, so there 
is enough time for the pre-computations. However, once an event occurred the 
reaction must be as fast as possible. Certainly, re-evaluation is worthwhile when 
compared to the evaluation if it can be performed in substantially less time than 
0(n). 

In this event-driven framework, the start-over algorithm can be regarded 
as having zero time precomputation and on-line re-evaluation of 0(n) time. 
Another example of the event-driven algorithm, introduced in |7], precomputes 
f{Xoid + A) for the subset {A : |A(Z\)| < d} and stores the precomputed values 
in the d-dimensional table. The precomputation takes time since the 

table has 0{n‘^) entries and 0{n) time is required for each entry to be computed. 
Upon event, the value corresponding to the particular S = X{A) can be restored 
from the table in time linear to the length of the list 0(|5|)(|(5| < d). 

The on-line algorithm presented in this paper uses the Index Decision Dia- 
gram to compute the result in time 0(|5|) = 0(|A(Z\)|). Precomputation is used 
to compose the IDD given a HDD and values of arguments X. Upon event, the 
algorithm finds value f{Xoid © A) using the IDD and given S. The problem of 
function’s re-evaluation is related also to the incremental methods of compu- 
tations. More specifically, re-evaluation using HDD is a particular case of the 
incremental circuit annotation problem m- 

3 Computation of Boolean Functions Using BDD 

Let vq and V denote respectively the root and the set of vertices of a BDD. 
Each non-terminal vertex v G V has exactly two outgoing edges called 0— and 
1— edge. When drawing a BDD, the 0-edge is depicted as a dotted line, and 
the 1-edge as a solid line. Target of the 0-edge is termed lo{v) and of the 1-edge 
hi(v). A non-terminal vertex is also associated with an input variable Xy,ind G X 
specified by the index v.ind{l < v.ind < n). 

A BDD has exactly two terminal vertices, associated with constant v.value G 
{0, 1} and assigned the pseudo index v.ind = n + 1. Each vertex v of the BDD 
denotes a Boolean function fy as follows: in the terminal vertices fy = v.value, 
in the non-terminal ones it is defined in a recurrent way: 

fy — Xy_indflo{v) V Xydndfhi{v)' (f) 

The function fy^ denoted in the root is said to be denoted by the whole BDD. 
There is a two-way relationship between functions and diagrams - each Boolean 
function also can be expanded into a BDD by iterative application of the Shan- 
non expansion [2]. 
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State X State X=<0,1,0,1,0> 





Fig. 1. Binary decision diagram with outlined active paths in the state X = (0, 0, 0, 0) 
(a) and after change i5 = (2, 4), i.e. at X + <5 = (0, 1, 0, 1) (b) 



A BDD is restricted (RBDD for short) if no variable is associated with more 
than one vertex in any directed path. Therefore length of any directed path in 
a RBDD is bounded by the size of the input array |A| = n. A BDD is ordered 
(OBDD) if in any directed path the indexes of the associated variables follow to 
the increasing order. Obviously, an ordered BDD is also restricted. 

At a fixed input X G {0,1}" one of the edges {v , lo{v)) , {v , hi{v)) is called 
active. If Xy,ind = 0 then (v, lo{v)) is active, otherwise the opposite edge (v.hi{v)) 
is active. The destination of the active edges is called the active successor of the 
vertex: w = actively). 



Let active'' {v) = 



I active{v) if i = 1 

active'~^{v) if z > 1 

denote the i — th active successor of v. A directed path starting in v, formed 
only of active edges, and ending in a terminal vertex is denoted 



v.Px = (v, active{v), active^ {v), .. . , active^ {v)') 



and called the active path of vertex v at input X. The subscript X emphasizes 
the dependence of the active path on the value of the current input. In particular 
if the input array contains only zeros, i.e. X — Q the active path is called zero- 
path of the BDD. A vertex v is called source of active path if it has no active 
incoming edges. An active path which starts in a source vertex is called full 
active path. 

Figure [T]-a presents an example of OBDD for the function 



/ = (xi © X2){x3 © X5) V (a:i © X2){x4 © X5). 
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Active edges corresponding to X = 0 are gray shadowed. The full active paths 
in this state of X are rooted in vq and V 2 '- vg-P = (uq, ui, U3, U5, U7), V 2 -P = 
(u2, U4, W6; t’s) respectively. 

The expression o can be transformed in terms of the active successor as 
follows: 



fv{^) factive(v)(X)- (^) 

The recursive computation of the function according to © can be performed by 
traverse of the BDD. The traverse starts in the root v = vq and always chooses 
the active child of the current vertex actively) to be continued. The value of 
the constant associated with the terminal vertex of the active full path v.Px 
determines the current value of the function fy(X). Therefore, time of the full 
computation of function using RBDD is bounded by 0{n). 



4 Index Decision Diagrams 

Let A = A (AT) denote an ordered list of indexes of ones in X. For example if 
X = (0000100101) then X{X) = (5, 8, 10). In this section we introduce the Index 
Decision Diagram (IDD) of a Boolean function which enables to compute f{X) 
in 0(|A(A1)|) time given the list A(A'). 

Let G be an ordered BDD which denotes the function /, and u.Pq the zero 
path. We define the search mapping M : V x {1,2, n} ^ V as follows: for given 
V € V and Vf G v.ind . . . n-|- 1: My{i) designates the vertex with minimum index 
greater than or equal to i in v.Pq. The Index Decision Diagram (IDD) £ = £{G) 
is a graph which is built for a given BDD G as follows: 

1. IDD and BDD have the same set of vertices Vs = Vq. 

2. A non-terminal vertex v G Vs has n — v.ind + 2 outgoing edges defined by 
array of their targets lihky[v.ind..n+ 1] such that: linky[v .ind] = hi(w), and 
the others n — v.ind + 1 edges are defined as link[i] = My{i),i = v.ind + 
1, .., n -I- 1. 

An example of IDD for the OBDD from Figure HJ-a is presented in Figure El 
Note that since the zero-path with source Vg does not contain vertex with variable 
X 4 , the corresponding links in the vertices vg, v\, vg are redirected to the vertex 
associated with xg. Similarly, in the zero-path with source in V2 variable xg is 
not included and the link in V2 is redirected to V4. 

The function denoted by the OBDD rooted in a vertex v depends on 
Xv.indj- ■ • j Xn. Let US represent the input subarray X[v.ind..n] as a concate- 
nation of some “leading zero’s” subarray Qv.ind..i and the remainder X[i..n]: 

X[v.ind..n] = 0[y,ind..z-i] ■ X[i..n]. 

If X is represented in such a way, i.e. if Xy,md = Xy,ind+i = •■ = Xi-i = 0, the 
following proposition holds: 
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5=<2,4> 




Fig. 2. Evaluation of IDD given the list A = (2, 4) 



Proposition 1. fy{X[v.ind..n]) = fM^(i){X[i..n]) 

Proof. Let us prove the statement by induction on i. If i = v.ind then My(i) = 
My{v.ind) = hi{v). According to |T1) if Xy,ind = 1 then /„ = fhi(v) so the 
statement holds. 

Assume that the statement holds for i = k > v.ind and prove it for i = k + 1. 
Denote w = My{k). According to the definition of My, w is such that w.ind is 
minimum w.ind > k. 

If w.ind = k then lo{w).ind > k+1 so My{k + 1) = lo{w). In case ofi = k+1, 
Xk = 0 which implies fM+k) = fw = fio(w) = fM+k+i){X[k + 

If w.ind > k (i.e w.ind > k) then My{k + I) = My{k) = w and fM„{k+i) = 

fM„(k)- 

Now suppose that the input vector is represented by the list A = A(A). If 
root of the BDD (and IDD) is v then w.l.o.g. we can assume X = X[v.ind..n] 
and min(X) > v.ind. Then 



^ ^[v.ind,min{x)—i] * X\min(^X) . .n] 

and according to the proposition [T] = /jvf^(^j„(;^p(A[mm(A)..n]). 

The evaluation of f{X) using IDD is performed by the algorithm presented 
in Figure El The input of the algorithm is list A, the output is the value of the 
function. Main loop [2]-[6] iterates no more than 2|A| times. In the body of the 
loop the current vertex v moves to v' = AA;(min(A)) in which fyi = fy. After that 
A is adjusted to not contain any number less than v' .ind so that the invariant 
v.ind > min{X) of the loop always holds. If the loop halts at v : v.ind < n+1 then 
there are no more indexes in A which means that Xy,ind = Xy,md+i = .. = Xn = 0. 
Therefore fy = fy{0y,ind..n) = /M„(n+i)- This is done in line [8]. 
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Algorithm IDD evaluation (A: list of integer) 

begin 

[1] u:=Root of the IDD; 

[2] while A is not empty do 

[3] Loop invariant is: {v.ind < mm(A)} 

[4] v' := Mv{min{\)) 

[5] Delete from A all numbers less than v' And 

[ 6 ] V := v' 

[7] end{ while } 

[8] if vAnd < n -|- 1 then v := M^(n -\- 1) 

[9] Result is v.value 

end 



Fig. 3. Algorithm re-evaluates function using as input the IDD and the list A of indexes 
of variables equal to 1 



Since the minimum of the ordered A is A[l] and computation of My(jnin(X)) 
is performed by the lookup in the linear array link in a constant time, the body 
of the loop takes constant time, so the total computation is done in time linear 
to 2|A|. A little modification of the mapping My is able to reduce the number 
of iterations to |A|: assume My{i) = My{i) for all i such that the corresponding 
Xi is not presented in the zero-path u.Pq, and My{i) = hi{My{i)) if Xi is in 
the zero-path. Then each iteration of the loop [2-6] makes min(X) > vAnd which 
guarantees at least one index from A to be deleted at each iteration thus bounding 
their number by |A|. However we sacrifice this improvement to the clarity of 
explanation. 

The algorithm of IDD evaluation is illustrated in Figure for AT = 
(0,1, 0,1,0), i.e. at A = (2,4). In the begin v = vo,min{X) = 2 and v moves 
to v' = My{2) = vi-ln V = Vi we have M„(2) = so that 2 to be deleted from 
A since v^And = 4 > min{X) = 2. Then v := M^^(4) = V 5 and 4 is also to be 
deleted from A. In this step the list A is exhausted, so according to the line [9] of 
the algorithm the result can be found as value attribute of vertex My^{ 6 ) = ug. 

The following theorem summarizes all stated above about the IDD evalua- 
tion: 

Theorem 1. The value of Boolean function f{X) can be computed by the algo- 
rithm of IDD evaluation in time linear to the number of ones in the argument 
vector X using its presentation as an IDD. 



5 Generation of IDD 

To build the IDD for a given OBDD G it is required to fill in every vertex v € Vq 
the arrays linky of pointers defining the edges going out of v in IDD. 
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Fig. 4. IDD edges in vertex v are formed using those of its active successor w in time, 
linear to n — i + 2 

Consider two adjacent vertices v and w in the OBDD, such that w = lo{v), 
v.ind = i,w.ind = j and j > i as shown in Figure IH According to the definition 
of IDD edges, in the vertex v: 

vdink[i] = hi{v), 

v.link[i + 1, . . . , j] = w, 

v.link[j + 1 . . . n + 1] = w.link[j + 1 . . . n + 1] 

Therefore the part v.link[j + 1 . . . n + 1] of the IDD links in v can be copied from 
those of w, while the others can be assigned each in a constant time. Complexity 
of the links generation, if the above routine is applied in down-up order from 
the vertices with higher indexes to the vertices with lower indexes is linear in 
the sum of links’ number by all vertices of the IDD (and OBDD): 

\Es\ = v.ind + 2 (3) 

vGVg 

In general the sum is upper bounded by 0{n |Vg|). 

6 Re-evaluation of Boolean Function Using IDD 

Let us denote x“ = a: if a = 1 and x“ = x if a = 0. Obviously, 0“ = a and 
a“ = 0. Let X = (ai, 02 , ■ ■ • , a™)- The normalized function fx is derived from a 
Boolean function / as follows: fx{xi,X 2 , ■ ■ ■ , x„) = /(x“^ , x^^^ , • ■ • , Value 
of the normalized function fx{0) with all-zeros argument 0 = 0, 0,... ,0is equal 
to the /(A): /x(0) = /(0“^0“^... ,0“") = /(«!, 02 ,... , an). 

The re-evaluation is required to compute the function after a change A is 
occured with the input: Xnew = A © Z\. The event-driven re-evaluation consists 
of the on-line part which follows the event denoted as a list 6 = A(Z\) and 
evaluates the new value of the function, and precomputation which is placed 
between events and provides the on-line part with required auxiliary data. 

In our case the auxiliary data consists of the IDD for the normalized func- 
tion fx- It is clear that f{Xnew) = fx{A). As it follows from the previous 
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section, having the IDD for the fx the value of fx{^) can be computed in 
time 0(|A(Z\)|). The OBDD for the normalized function can be derived from 
the OBDD denoting / trading places of its 0— and 1— edges in all the vertices 
V : Xv,ind = 1. It can be easily observed for a single- variable case with OBDD 
with one non-terminal vertex and then proved by induction for an arbitrary 
OBDD. Time of the transformation is bounded by 0{V). Given the OBDD for 
fx, the IDD for fx is composed in 0{n\V\) time, so the total precomputation 
required is bounded by 0{\V\ + n |G|) = 0{n |y|). Given the precomputed IDD 
and the list S of indexes of changed variables the re-evaluation requires 0(|(5|) 
time to find the new value of the function. 

We summarize this result as the following theorem: 

Theorem 2. On-line re-evaluation of a Boolean function f : {0, 1}" — >■ {0, 1} 
after a change A to the input X can he done in time 0(|A(Z\)|) at the precom- 
putation of 0{\V\n) time. 
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Abstract. Industrial-size specifications/models (whose state space is of- 
ten infinite) can not be model checked in a direct way — a verification 
model of a system is model checked instead. Program transformation is 
a way to build a finite-state verification model that can be submitted to 
a model checker. Abstraction is another technique that can be used for 
the same purpose. This paper presents a transformation of SDL timers 
aimed at the reduction of the infinite domain of timer values to a finite 
one with preserving the behaviour of a system. A timer abstraction is 
proposed to further reduce the state space. We discuss the ideas behind 
these transformations and argue their correctness. 



1 Introduction 

Model checking is one of the most popular and successful verification tech- 
niques accepted both in academia and in industry. One of the main reasons of its 
success is its promise to automatically check a program against a logical specifi- 
cation, typically a formula of some temporal logic. A stumbling-block limiting the 
model-checking application area is the notorious state-space explosion. The ma- 
jor factors influencing the state space are, clearly, the size and the complexity of 
a specification. In many cases, abstractions and compositional techniques make 
it possible to cope with the state-space explosion and apply model checking to 
real-life industrial systems (see e.g., [12]) • However, besides size and complexity, 
there exists another factor cumbering verification. 

Development of a specification language, its semantical concept are greatly 
affected by the intended mode of its use, its application domain. Often, the 
final objective is to provide an executable specification/implementation. In that 
case, the specification language and its semantics should provide a framework 
for constructing faithful and detailed descriptions of systems. No wonder that 
specifications written in these implementation-oriented languages are harder to 
verify than the ones written in the languages developed as input languages for 
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model checkers. In this paper, we concentrate on some aspects of modelling 
time in the implementation-oriented languages, taking SDL (Specification and 
Description Language) [TT] as an instance of this class of languages. 

SDL is a popular language for the specification of telecommunication soft- 
ware as well as aircraft and train control, medical and packaging systems. Timing 
aspects are very important for these kinds of systems. Therefore, behaviour of 
a system specified in SDL is scheduled with the help of timers involved into the 
specification. The model of SDL timers was induced by manners of implemen- 
tation of timers in real systems. An SDL timer can be activated by setting it to 
a value (NOW -I- S) where expression NOW provides an access to the current system 
time and J is a delay after which this timer expires, i.e., the timer expires when a 
system time (system clock) reaches the point (N0W-|-(5). Such an implementation 
of timers immediately means that the state space of SDL-specifications is infinite 
just due to the fact that timer variables take an infinite number of growing, dur- 
ing the system run, values. An inverse timer model is normally employed in the 
verification-oriented languages: a timer indicates a delay left until its expiration, 
i.e., a timer is set to value S instead of (NOW -|- J), and this value is decreased 
at every tick of the system clock. When the timer value reaches zero, the timer 
expires. This model of timers guarantees that every timer variable takes only a 
finite (and relatively small) number of values. 

Another SDL peculiarity that adds to the complexity of verification is the 
manner the timers expire in SDL. SDL is based on the Communicating Extended 
State Machines; communication is organized via the message passing. For the 
uniformity of communication, timers are considered as a special kind of signals 
and a process learns about a timer expiration by dint of a signal with the name of 
the expired timer, inserted in the input port of the process. From the verification 
point of view it would be better if a timer expiration had been diagnosed by a 
simple check of the timer value. 

Though formal verification of SDL-specifications is an area of rather ac- 
tive investigations 1218161101141 , the time-concerned difficulties were being got 
round for a long time by means of abstracting out time and timers. Due to 
engineering rather than formal approaches to constructing abstractions, some 
of proposed abstractions turned out to be not safe (see for details). In [^, 
a toolset and a methodology for the verification of time- dependent properties 
of SDL-specifications are described. The SDL-specifications are translated into 
DT Promela, the input language of the DT Spin (Discrete Time Spin) model 
checker U, and then verified against LTL formulas. Some arguments in favour 
of a behavioural equivalence of the DT Promela translation to the original spec- 
ification are given. 

Here, we propose a transformation of SDL specification into SDL itself, where 
the new timer variable type is substituted for the traditional SDL timer type. 
The underlying idea is similar to the one in [2], but providing SDL to SDL 
transformation, we make the transformation principles independent of a partic- 
ular model checker, and the formal proof of model equivalence substantiate that 
the transformed model can be safely used for the verification. 
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Admitting that in a number of cases timer abstractions are usefufl, we believe 
that the safe timer abstraction of j2| does not yield a desirable result in a number 
of situations because it abstracts not just timers but time. Here we propose a 
more flexible w.r.t. the refinement degree abstraction, for which the abstraction 
of is a particular case. 

The paper is organised as follows. In Section |2] we outline the SDL seman- 
tics we use. In Section |3] we present a behaviour-preserving transformation for 
SDL-specifications. In Section E] we propose a timer abstraction. We conclude in 
Section E]by evaluating the results. 

2 SDL Time Semantics 

SDL is a general purpose description language for communicating systems. The 
basis for the description of a system behaviour is Communicating Extended 
State Machines represented by processes. A process consists of a number of 
states and a number of transitions connecting the states. The input port of a 
process is an unbounded FIFO-queue. Communication is based on the signal 
exchange between the system and its environment and between processes within 
the system. 

A specification Spec is the parallel composition Pi of a finite number 

of processes. A process P is specified as a tuple {Var,Timer,Loc,Edg,q,"fo), 
where V ar is a finite set of variables, Timer is a finite set of timers, Loc is 
a finite set of control states, or locations, g is a process queue, and 70 is an 
initial configuration. A valuation of process variables maps a process variables 
to values, i.e., Var — > D, where D is some data domain. A configuration 7 of a 
process is a control state I together with a valuation of variables 9, a valuation 
of timers and a process input queue q. We denote the set of valuations by 
Val and the set of configurations by P. The set of edges Edg C Loc x Act x Loc 
describes changes of configuration resulting from performing an action from a 
set of actions Act. 

We distinguish the following actions: (i) input of a signal s containing a 
value to be assigned to a local variable, (ii) output of a signal s together with a 
value described by an expression to a process P' , (iii) assignments, (iv) setting 
and resetting a timer. In Loc, we distinguish a set Loci of input locations, i.e., 
the locations where input actions are allowed. Note that it is the only sort of 
actions allowed in these locations. We assume a boolean guard g to be imposed 
on each action, and in every location, besides input locations, at least one guard 
is evaluated to true. The input actions are denoted as g\>ls{x), outputs as 
g\> P'\s{v), assignments as g\>x\ = exp, setting and resetting of a timer t as 
g [> SET(ea:p, t) and g > RESET(t) respectively. 

The step semantics of a process is a labelled transition relation on configura- 
tions, — P X Label x P. Internal steps are denoted by r, the time-progress 
steps by tick and communication steps are labelled by a triple of process, sig- 
nal and value to be transmitted. The behaviour of a single process is given by 

^ If a property is expected to hold independently of the settings of a timer, for example. 
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Table 1. Step semantics for process P 



I — >g[^ 7 s(x) I £ Edg = true I G Loci s ^ Sig-,., 

{l,e,4>,s{v) ::q) -^r {i,d[x^v],(j},q) 

I — >- 9 >?nohe I G Edg [yle = true I € Loo, 



■ Input 



NoneInput 



{l,e,4>,q) -^r {l,e,(j),q) 

I — >g > 73 /( 2 ;) I G Edg ^ s' ^ s I £ LoCi s 0 S’lijj, 
{l,e,cj),s{-) :-.q) {l,e,4>,q) 



Discard 



V £ Val 

Receive 

{I, 9, (f>, q) — >PTs{v) (1, 6,(t>,q-- s{v)) 

I — >gi> p'\sO) I £ Edg {gje = true |els = n I ^ Loa 

; Output 

{l,e,(j>,q) ~^p']s(v) {l,9,(j),q) 

I — ^g> 2 : := exp I £ Edg Igije = true \exp\e =v I ^ Loa . 
; Assign 

il,6,(j>,q) (1, 9[x v], <^, q) 

I — >-9 > sET(e7:p.t) 1 £ Edg = true \exp\e =v I ^ Loa ^ 

; Set 

{l,e,(j),q) -^x {1,9 on(v)],Tlt{q)) 

I — >-g>RESET(t) i G Edg = true I ^ Loa 

; Reset 

{l,9,(j),q) -^x {l,9,(f)[te^off],'Xt{q)) 



|N0W]]^ = V ltj,p = on{v) 

Expiration 

{I, 9, (j), q) -s -2 {I, 9, (j>[t e^off],q--.t) 

I — >gt>n I £ Edg {gjo = true I £ Loa t G Sig^i, 
{l,9,(j),t-.-.q) -^x {l,9,cj),q) 

I >g >?s( 2 !) I G Edg ^ s ^ t I £ Loa t £ /Siffameout 
{l,9,(j),t\\q) -^x {l,9,<p,q) 



■ TInput 



TDiscard 



sequences of configurations 70 — tA 7i — 5 >a Table [H gives the step semantics 

of a process P, where we assume Sig^^j^ieout to be the set of timer signals. We 
write e for an empty queue, s{v) :: q for a queue with message s{v) at the head of 
the queue, i.e., s(u) is the message to be read from the queue next; q :: s(v) de- 
notes a queue with s(r) at the tail. The notation 6 [ xexfv ] stands for the valuation 
equalling 9 for all y £ Var\{x} and mapping a variable x to a value v. 

The rule Discard captures a specific feature of SDL92: if the signal from the 
head of the queue does not match any input defined as possible for the current 
(input) location, the signal is removed from the queue without changing the 
location and the valuation. NoneInput defines the SDL NONE transition, which 
is a spontaneous transition from a location I to the location 1 . 
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In SDL, the concept of timers is employed to specify timing conditions im- 
posed on a system. Two data types, Time and Duration, are used to specify time 
values. A variable of the Time type indicates some point of time. A variable of 
the Duration type represents a time interval. A process can access the current 
system time by means of the NOW operator, which we replace for simplicity by 
shared variable NOW. Each timer is related to a process instance; a timer is either 
active (set to a value) or inactive (reset). Two operations are defined on timers: 
SET and RESET (rules Set and Reset). A timer is activated by setting it to a 
value (now -T 6) where i5 is a delay after which this timer expires. The RESET 
action sets the timer to off . 

With each timer there are associated a pseudo-signal and an implicit tran- 
sition, called a timeout transition. When a timer expires, its timeout transition 
becomes enabled and may occur. The execution of the timeout transition, cap- 
tured by the Expiration rule, adds the corresponding pseudo-signal to the 
process queue and reset the timer to off. If a SET or RESET operation is per- 
formed on an expired timer after adding the timer signal to the process queue 
(before the signal is consumed from the queue) , the timer signal is removed from 
the queue. We write TTt{q) for the queue obtained from q by projecting out the 
timeout signal t. 

The global transition semantics of a specification Spec is given by a standard 
product construction: configurations are paired and global transitions synchro- 
nize via their common labels. The global step relation — P x Label x P is 
given by the rules of tabled Asynchronous communication between the two pro- 
cesses uses a signal s to exchange a common value v, as given by rule COMM. As 
far as r-steps and communication messages using signals from the environment 
{^^9 ext) concerned, each process can proceed on its own by rule Interleave. 
Both rules have a symmetric counterpart, which is omitted. 

Time elapses by counting up the actual system time represented by NOW. 
Though there is no standardized time semantics in SDL, there exist two se- 
mantics widely accepted in the SDL-community |^. According to one of them 
(the one, which is supported by the commercial SDL-design tools |15I13J and 
the one we work with), the transitions of SDL processes are instantaneous (take 



Table 2. Parallel composition 



71 -^p\s{v) 71 72 — >pis{v) 72 

Comm 

7i X 72 ~^T 7i X 72 

7i 7i A = {r, Pls{v), P\s{v) \ s G 

Interleave 

7i X 72 ->-A 7i X 72 

blocked {'y) 

Tick 



NOW ^tick NOW -L 1 



A Transformation of SDL Specifications — A Step towards the Verification 



69 



zero time), time can only progress if the system is blocked: all the processes 
are waiting for further input signals (i.e., all input queues are empty, except for 
saved signals, and there is no NONE input enabled). Tick expresses it by the 
predicate blocked on configurations: blocked{'y) holds if no move is possible in 
the system except a clock-tick, i.e., if 7 — )>> for some label A, then A = tick. 
In other words, the time-elapsing steps are those with least priority. Due to the 
discarding feature, blocked {'j) implies then q = e. 

Later on, we refer to a segment of time separated by the time increment 
transitions as a time slice. (Note that time progression is discretised.) When 
the system time gets equal to some timer value, the timeout transition becomes 
enabled (Expiration) and it can be executed at any point of the time slice. The 
time slice always starts with a firing of one of the enabled timeout transitions. 
This action unblocks the system. In case several timeout transitions become 
enabled at the same time, one of them is taken (non-deterministically) to unblock 
the system and the rest are taken later at any point of the time slice since they 
have the same priority as normal transitions. 

Though complicated, such a time semantics is suitable for implementation 
purposes m . It is natural to model a timer as a unit advancing from the current 
moment of time derived by evaluation of NOW expression to the the time point 
specified by the expression (NOW-I-A), i.e., waiting for a point of the system time. 

3 Timer Transformation 

A configuration of an SDL process is described by its current location, the val- 
uations of timers and variables, and the content of the input queue. Since NOW 
gives an access to the current system time, executing SET(NOW-|-ea:p, t) with dif- 
ferent (infinitely growing) values of NOW, we get different process configurations. 
Moreover, a timeout transition can add a timer signal at any point of the time 
slice. This blows up the state space due to the number of possible interleaving se- 
quences of events. And furthermore, keeping a timeout signal in a process queue 
adds to the length of the state vector. Therefore, the way of modelling timers 
in SDL is not quite suitable for the model-checking purposes. In this section, we 
solve this problem by transforming SDL specifications, replacing a concept of 
timers with a new one. 



3.1 Transformation Rules 

To avoid the state-space explosion due to the interpretation of timers and the 
overhead caused by the management of timeout signals, we substitute the SDL 
concept of timers as a special kind of signals by a concept of timers as a special 
data type. A timer variable t represents declared in the original specification 
timer t. The value of this variable shows the delay left until the timer expiration. 
Since delays are non-negative, we use —1 to represent inactive timers. Therefore, 
the RESET(t) operation is transformed into the assignment of the —1 value to a 
timer variable t (Table 13] rule Reset to Assignment III) and the SET(NDW -I- 
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Table 3. Transformation Rules 



I 



;t>?t I e Edg t € Sig^ 



>■[9 A(t=0)] [>?H0BE ^(true) t> t: = -l ^ £ Edg 

— >'9 > SET(nau+ea;p,i) ^ £ Edg 



TInput to TimeoutI 



^[9A(ea;p > 0)] > t: — eajp ^ ^ Edg 
■^9 > SET(HDW+ca:p,t) I £ Edg 



Set to Assignment! 



^ [9 A(^3;p<0)] C> f:— 0 ^ ^ Edg 
■t 9 >RESET(t) I £ Edg 



Set to Assignment!! 



"tg > t~-i I £ Edg 
^g\>?s{x) ^ ^ Edg s^t 



Reset to Assignment!!! 

^ ^ timeout 



i ^(t=0)>?BDnE ^(true) C> t: = -l I £ Edg 



TDiscard to Timeout!! 



exp, t) operation is transformed into the assignment of exp in case exp > 0 
(Table E] Set to Assignment!), or the assignment of 0 in case exp < 0 (Table 
E] Set to Assignment!!). 

!n the original system, a timer whose value in the original system is less than 
or equal to the current system time may expire. The transformed system should 
demonstrate the same behaviour. Since we suppose the value of a transformed 
timer to be a delay left until its expiration, only the timers whose values are 
equal to 0 may expire. Therefore, we replace inputs of timeout signals by the 
NONE input guarded by the (t = 0) condition, followed by timer deactivation 
(Table El rule T!nput to Timeout!). A possible discard of a timeout signal is 
imitated by analogous actions (Table E] rule TDiscard to Timeout!!). Fig.|T] 
illustrates the application of the transformation rules. 
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Fig. 1. Transformation scheme 
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Table 4. Step semantics for transformed specification 



I — >gt> X := exp I £ Edg [dtf = truc [exp]]^ = v x e TV ar 

; TAssign 

blockedU, ip, q) 

Tick 

(l,d,(fi,q) -^tick {l,&,lfi[te^dec(t)],q) 



Table |H gives the modifications of the step semantics caused by the timer 
transformation. TAssign defines the semantics of assignments for the timer 
variables. The rules Input, Discard, Assign, Output, Receive, Comm and 
Interleave coincide with ones of Table[H and, therefore, omitted. Note that the 
system time is not present in the transformed system — one infinitely growing 
variable would be enough to cause the state-space explosion. Instead of increasing 
the system time, the tick transition (rule Tick of Table 3) decreases the values 
of timer variables. Like the Tick transition of the original system, this transition 
can take place only if the system is blocked, and “blocked” has exactly the same 
meaning as before. The dec operation decreases all the positive values of timer 
variables by 1 and leaves the others unchanged. 

Note that the transformation rules are developed under the assumption that 
NOW operator appears in the system in the scope of SET operations only, and all 
the SET operations are of the form SET(N0W-T(5, t). In the sequel, we consider the 
systems of this type. In case NOW is employed in a specification for measuring 
time intervals between, these fragments of the specification can be respecified 
with the use of an additional timer variable. 

3.2 Model Equivalence 

The transformed system does not give a straightforward reflection of the origi- 
nal system behaviour. While the actions that are not related to timers are left 
unchanged, sendings of timeout signals are projected out, and consumptions of 
timeout signals from the process queue are mimicked by the corresponding NONE 
inputs, whose enabling conditions are guaranteed to be true in this case. Such 
a projection is not harmful from the verification point of view because not the 
presence or absence of a timeout signal but the consumption of it and the choice 
of the following actions are important. The same concerns process queues: saying 
that the content of some queue in the transformed system is the same as the 
content of the corresponding queue in the original system, we mean that the 
projections of the queues on Sig \ Sigumeout coincide. The main requirement 
imposed on the configurations is that the valuations of variables should equal: 

Definition 1 (relation ss on configurations). Let 7 = {l,9,(j),q) and 7' = 
(Z', 0', Lp, q') be configurations of processes P and P' . We write 7 w 7' iff for any 
X G Var : \x\g = |a:]e/. 
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Definition 2 (simulation). Let P and P' be two proeesses with sets of eonfigu- 
rations P and P' and R C P x P' a relation on eonfigurations. R is a simulation 
iff R Css, and {'jR'y' and 7 7) implies that at least one of the following 

conditions holds: 

1. 7' — >-A 7^ and fR'Y, for some configuration ; 

2. X = T and ^Rff ; 

3. 7' — ■ ■ ■ ~^T 7 n y for some n > 0 such that ^Rf and 'jR'yl for 
allff,. 

We write P ^ P' , if there exists a simulation relation R such that 70-R70 for the 
initial configurations 70 and 7q of P and P' respectively. 

The definition of simulation is analogously used for systems. 

Lemma 1. For all formulas g) from next-free LTL mentioning only variables 
from Var, S P S' and S' \= g: implies S \= g:>. 

Definition 3. Let P' be a process derived from a process P using the transfor- 
mation rules defined in Table 0 7 = (l,0,4>,q) and 7' = (V ,0' , g},q') be their 
configurations and NOW be the system time related to process P. We say that 
(7,N0W)(57^ iff the following conditions are satisfied: 

1. i; 

2. q' = SigtimBoutil) > where T^’Sigumeo.^tid) obtained from q by projecting out 
the signals from Sigumeout; 

3. if |t]0 = on{v) and = k then k + |N 0 W] = max{|N 0 W] , u}; 

4- if PI0 = off and a timeout signal t is not in q then |t]^ = —1; 

if W0 = off and a timeout signal t is in q then |t]y, = 0. 

This relation Q can be lifted up to systems. 

Lemma 2. Let S' be a system derived from a system S according to the trans- 
formation rules defined in Table 0 7 and 7' be configurations of S and S' re- 
spectively, and jQff . Then blocked{'f) iff blocked{ff) . 

Theorem 1 (simulation). Let S and S' be systems defined as above. Then Q 
is the simulation relation on their configurations, S ^ S' . 

Proof sketch. It is straightforward to check on the rules of Tables H] 0 2]that for 
single processes P ^ P'. There, for the case of Expiration in P take no step 
in P' , for the case of TInput take TimeoutI, and for the case of TDiscard 
take TimeoutII. For systems, prove that Pi ^ P[ and P2 P P2 implies Pi || 
P2 di P{ \\ P^j proceeding similarly by case analysis on the rules of Table 0 using 
Lemma 0 □ 

Ideally, we would like Q~^ to be a simulation relation as well, and establish 
by that a bisimulation between S and S'. However, it is not the case — an at- 
tempt to establish a simulation in the reverse direction fails while considering 
the Timeout case in the transformed system. In principle. Timeout should 
be mimicked by taking Expiration and TInput. But the Expiration step in 
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the original system cannot be taken earlier than the decision about Timeout is 
taken in the transformed system. On the other hand, when Timeout is taken, it 
could be already too late to take the Expiration step, since the process queue 
of the original system can be non-empty, which would mean that the timeout 
signal could not be immediately consumed from the process queue. We solve this 
problem by proving the trace inclusion for S and S' . 

Definition 4 (trace). Let N be a set {0,1,2,... ,n}. We say that a pair of 
mappings a = a\) with : N — > F and u\ \ N\ {0} — > Label is a trace 

of length n generated by a system S with a set of configurations F iff for any 
i : 0 < i < n, — >-£,,,(^+ 1 ) cr^fi -|- 1) js a step of S. 

In case N = N we say that a is an infinite trace. 

Definition 5 (equivalence of traces). Let a and a' be traces of length n, 
n' generated by systems S and S' resp. We say that a =tr <j' iff there exists 
U Q N X N' such that 

1. {i,j)€U implies crj(i) ~ cr(,(j). 

2. For any i : 0 < i < n, there exists j ■ 0 < j < n' such that (i,j) € U. 

3. For any j '■ 0 < j < n' , there exists i : 0 < i <n such that (i,j) G U. 

4- For any i,j : 0 < i < n, 0 < j < n' , (i,j) € U implies that one of the 
following conditions holds: 

- CTx{i + 1) = cr'^U + 1) A {aj{i + l),cr(y(j + 1)) & U A 

(VA: : 0 < k < i + 1 : {k,j + l) ^ U) A (Vfc : 0 < fc < j -I- 1 : (i + l,k) ^ U); 

- a\{i -I- 1) = r A {aj{i + 1), crly(j)) € U A (VA: : 0 < k < j : {i + 1, k) ^ U); 

- cf\{j -I- 1) = r A {aj(i),a!y{j + 1)) G U A {Vk : 0 < k < i : {k, j + 1) ^ U) . 

We write S' <tr S ijf for every trace a' of S' there exits a trace a in S such that 
a =tr cr'. 

Lemma 3. For all formulas ip from next-free LTL mentioning only variables 
from Var, S' <tr ^ o,nd S \= ip implies S' ^ p. 

Theorem 2 (trace inclusion). Let S' be a system derived from a system S 
according to the transformation rules defined in Table\^ Then S' pftr S. 

Proof sketch. For an arbitrary trace a' of S' , we are constructing an equivalent 
trace in S. We impose an additional condition on Lf that (z,j) S U implies that 
aj{i)Qa'^{j). Then construct a trace a of S and a relation Lf between traces 
by induction on the length of a' , applying the stepwise simulating of a' with a 
special treatment of the Timeout case. For Timeout, insert the Expiration 
step at the appropriate place in the constructed trace, modifying U respectively 
(by shifting the tail of a in U), and then take TInput or TDiscard respectively. 

□ 

Corollary 1. Let S and S' be systems defined as above, and p a next-free LTL- 
formula mentioning only variables from Var. Then S \= p ijf S' \= p. 
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4 Timer Abstraction 

Abstraction, intuitively, means replacing one semantical model by an abstract, 
in general, simpler one. In addition to the requirement that an abstract (verifi- 
cation) model should have a smaller state space than the concrete (implemen- 
tation) one, the abstraction needs to be safe, which means that every property 
checked to be true on the abstract model, holds for the concrete one as wel|j. 
This allows the transfer of positive verification results from the abstract model 
to the concrete one. 

The concept of safe abstraction is well-developed within the Abstract Inter- 
pretation framework SEl- The requirement that Abstract Interpretation puts 
on the relation between the concrete model and its safe abstraction can be for- 
malized as a requirement on the relation between the data operations of the 
concrete system and their abstract counterparts as follows. Every value of the 
concrete state space is mapped by the abstraction function a into an abstract 
value which, intuitively, “describes” the concrete value. On the other hand, the 
concretisation function 7 maps each abstract value to a set of concrete values 
that are described by the abstract value. Abstract states are ordered according 
to their precision: x°^ ^ y°‘ 44- C 7 ( 1 /“). For every operation (function) 

fconc on the concrete state space, an abstraction fabs needs to be defined which 
“mimics” fconc- In general, the abstraction can be nondeterministic. This is for- 
mally captured by letting fabs be a function into the powerset over the domain 
of abstract values. The requirement of mimicking is then formally phrased as: 

Vcc e Val 3y € fabs{a{x)) : a{fconc{x)) ^ y 

Further we call this the safety statement. 

Besides decreasing the state space of the system and safety, the main require- 
ment for an abstraction is that the abstract system behaviour should correctly 
reflect the behaviour of the original system with respect to a verification task 
in the sense that an abstraction captures all essential points in the system be- 
haviour, i.e., it is not “too abstract”. The safe abstraction of timers for Promela 
translations of SDL-specification from [2] does not meet this requirement well 
enough. 

The abstraction in [2] is based on a natural idea of allowing timers to expire 
at an arbitrary moment after they are set. A typical problem arising when one 
starts to apply this abstraction in practice is introducing zero-time cycles which 
are not present in the concrete model. A usual pattern for SDL-specifications 
is that a timer schedules some periodical activity; after a timer-out signal is 
consumed by a process, some actions are taken, the timer is set again, and the 
process returns to the same control state where it was before the consumption of 
the timer signal. Since the abstraction allows a timer to expire at any arbitrary 
moment after its setting (also immediately after it has been set), an undesirable 

^ A safe abstract system is, intuitively, a system whose behaviour (the set of all tran- 
sitions) is a superset of the concrete system behaviour. 
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cyclic behaviour can be introduced. The “timeout input - timer setting - timer 
expiration” chain of transitions can be executed infinitely many times and all 
the other behavioural branches may be ignored forever. Therefore, the properties 
which hold for the concrete model and which are expected to hold independently 
of the timer settings, fails to hold for the abstract model since “independently” 
means in this case that the property holds for the concrete model whatever 
positive delay is assigned to a timer. Another problem arises in case a timer 
serves as a guard preventing from taking a transition too early. With abstracting 
time, this timer guard is broken. 

We propose an abstraction for timers that keeps this guard delaying the timer 
expiration. A concrete timer that can be set only to delays exceeding some k is 
abstracted according to the rules given in Table E] The setting of the concrete 
timer to a (NOW + x) value is replaced with setting it to (NOW + k) (assuming 
X > fc to be an invariant for the setting operations), and the timer is allowed to 
expire at any point of time after the delay of k time units (see Fig. E|). Varying 
k, we can change the refinement degree of the abstraction. Taking k equal to 0, 
we get the most abstract version of it, which is an abstraction from [2] where 
not just timers but time is abstracted. Taking k equal to the lower boundary of 
the timer delays in the system, we get the most refined abstraction that can be 
obtained with this abstraction schema. 



Table 5. Abstract SET and INPUT operations 



: set 

i — t> SET(Baw+fc,i) i G Edg 

>g i G Edg t G 

; ExpireNow 



I — ^g[>?t t G Edg 
t>?t i e Edg te 

ExpireLater 



I — ^g — ^(true) > SET(nDw+i,t) i G Edg 

^ ^g >?s(x) t £ Edg ^ s ^ t Z G LoCi t G Sig^^ ^ 

Ad DiscardNow 

I — >g |>?t I G Edg 

I >g >?s(!r) i £ Edg ^ s ^ t Z G LoCi t G 

DiscardLater 

t — ^g>?t — ^(true) > SET(naw+i,t) I & Edg 



Now we shall show that this abstraction only adds behaviour while preserving 
all the behaviour of the concrete system. Since the timer semantics described in 
Section0is simpler than the original SDL semantics, it is easier to prove safety of 
the abstraction w.r.t. transformed systems. Table Ogives the abstraction rules 
for the transformed system S' derived by applying the transformation to the 
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Fig. 2. Abstraction scheme 



abstraction rules from TableO Let S' be a concrete system and qS its abstraction. 
Consider systems S' and aS' derived from S and q,S using the transformation 
rules from Table O Then (due to Corollary [T|) we have the property preservation 
directions from S to S' and from ^S' to qS. So it remains to show that aS' is a 
safe abstraction of S'. 

In order to distinguish the values of timer variables in the abstract system 
from their values in the concrete one, we write 1“ , 2 “ , . . . , for the abstract 
values. The abstraction function a and the concretisation function 7 are then as 
follows: 



if a; > k, 

x[x) = ■^ if 0 < a: < fc, 

-1“ if a; = -1; 



7 (^“) 



Hence, we have >~ 1°^ k°‘ . 



{y\y^x} if 0“ < a:“ < 
{— 1} if a:“ = —1. 



Lemma 4. The abstraction defined by the rules of Table El is safe. 

Proof sketch. It is straightforward to check on the rules of Table E]that the safety 
statement is not violated. 



Lemma 0 implies that we have the property preservation in the direction 
from aS' to S", which immediately gives the following conclusion: 

Theorem 3. Let aS be a system derived from a system S using the abstraction 
rules given in Table\^ (p a next-free LTL-formula mentioning only variables from 
Var, and S' |= ip. Then S \= ip. 

The verification experiments showed that the smallest number of states is 
usually obtained with abstractions where k is equal to 1, not 0. (We compare 
the number of states in the models, to which the transformation from SectionOis 
applied.) The state space normally grows with increasing k, which is no wonder 
since the number of possible states of the timer itself grows in that case. Rather 
unexpected was the fact that taking k equal to 0 increases the state space and can 
lead to the state-space explosion. The behaviour of the system with zero timer 
delay often has a different nature of regularity, the behaviour branches excluded 
formerly by the timer guards can be taken, which explains this phenomenon. 
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Table 6. Abstraction rules for a transformed system 



I O t: — X ^ ^ ^^9 1 ^ 1 ^ ^ 



I 



TAssignI 



>g > t--x i G Edg 0 < |a ;]^3 < fc 



TAssignII 



/ ygt>t:—x I G Edg 

■^[g/\(t=0)] >?HDNE ^(true) t> t: = -l ^ G Edg 

A(t=o)] |>?N 0 HE — ^(t7-ue) > t~-i“ I G Edg 
■t[g A(t=o)l >?»[)»£ — ^(true) >t~-i I G Edg 



TimeoutNow 



■^[g A(*=0)1 ^(true)t>t~l I G Edg 

tg > t: — — l I G Edg 



TimeoutLater 



I >-g>t: = -l“ I G Edg 



TAssignIII 



5 Conclusion 

The proposed transformation of SDL-timers is a simple and inexpensive step 
that can be considered as a zero-phase of the translation of SDL-specifications 
to a model-checker input language. The transformation is aimed at reducing 
the state space to a finite domain. A side issue (though important on its own) 
is that the described transformation gives a different insight into the timer se- 
mantics. Our experience shows that the complicated time semantics of SDL can 
lead to errors due to its misunderstanding both in the design-phase and in the 
translation-phase (cf. mni)- Treatment of timers as variables is simpler than 
treatment them as signals. Moreover, the transformation removes the concept of 
global time, whose existence does not look realistic for many sorts of distributed 
systems. 

The abstraction of timers is aimed at the state space reduction. Due to its 
flexibility, it is applicable to a wider range of problems that the earlier used for 
SDL timer abstractions. Its practical application confirmed its efficiency for the 
real-life situations (see 1121 1. 
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Abstract. We propose a symbolic model checking procedure for timed 
systems that is based on operations on constraints. To accelerate the ter- 
mination of the model checking procedure, we define history-dependent 
widening operators, again in terms of constraint-based operations. We 
show that these widenings are accurate, i.e., they don’t lose precision 
even with respect to the test of boundedness properties. 



1 Introduction 

For the last ten years, the verification problem for timed systems has received 
a lot of attention (see e.g., The problem has been shown to be 

decidable in Pj. Most of the verification approaches to this problem have been 
based either on a region graph, which is a finite quotient of the infinite state 
graph, or on some variants of it (that use convex/non-convex polyhedra and avoid 
explicit construction of the full graph). But, as we show below, region-graph 
based approaches (or its variants) cannot be used for dealing with boundedness 
(unboundedness) properties. This is due to the fact that the partitioning of the 
state space induced by the region equivalence (or any other technique that takes 
into account the maximal constant in the guards) is guaranteed to be pre-stable 
but may not be post-stabl^ 

A boundedness property is of the form 3/c > 0 AG{x < k) where a: is a clock 
(read this specification as: there exists a nonnegative k such that for all paths 
starting from the initial position, the value of the clock x does not exceed k 
throughout the path) . An unboundedness property is the dual of a boundedness 
property: Vfc > 0 EF{x > k). These properties are useful in verification because if 
the designer knows that the value of a clock should never exceed a constant, then 
satisfaction of an unboundedness property by the design immediately informs 
the designer of a possible bug in the design. Also, the implementor can use this 
information to save some hardware while implementing the design (in hardware). 
Obtaining such information usually requires lot of insight. 

Consider the timed automaton (see [2] for a definition of timed automata) 
given in Figure [T] (it has two clocks x and y and four locations 0, 1, 2 and 3; the 

^ the definitions of pre-stable and post-stable partitions can be found in |l|. 
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guards and resets for the edges are indicated at the top of or beside the edges; 
the invariants of the locations are indicated above or below the locations). Let 
us try to see whether the system satisfies the property > 0 AG{x < k), where 
the clock X in the formula refers to the clock x in the automaton. If we use the 
region graph technique, we will see that the regions (the maximal constant is 
2 here) (1 < j/ < 2,a; > 2), (y = l,cc > 2) and (0 < y < l,a; > 2) (we do 
not enumerate all the reachable regions; the variables x,y range over reals) are 
reachable. One may now conclude, on the basis of this reachability analysis, that 
the automaton does not satisfy the above boundedness property (note that all 
the three regions given above are unbounded). Unfortunately, this is not true; 
the value of the clock x never exceeds 6 (just six) ! Region graphs (or its variants) 
cannot be directly used for model checking for boundedness properties! 




Fig. 1. Illustrating unboundedness (boundedness) property 



Now consider a reachability analysis for this timed automaton using the 
algorithm in Figure [9| (this algorithm is a well-known simple symbolic for- 
ward reachability analysis algorithm; due to lack of space it is provided in 
the Appendix). The algorithm terminates generating the following set of reach- 
able states: {L0{x,y),x = 0,y = 0), {L0{x,y),x = y,y > 0,y < 2), 
{lA{x,y),0 < X < 2,y = 0), {lA{x,y),x - y > 0, y - x > -2, y > 0, y < 2), 
(L2(x,y),0 < X < 4,y = 0), (L2(x,y),x - y > 0, y - x > -4, y > 0, y < 2), 
(L3(x,y),0 < y < 2,x = 0) and {lA{x,y),x — y > 0,y < 2,x > 0) (the states 
are tuples of locations and constraint stores; we write I A for the location i; sym- 
bolic forward reachability analysis for the timed automaton in Figure[T] produces 
these constraints). It can be easily found out from the set of reachable states 
(by projecting the constraints on the x-axis) that the value of the clock x never 
goes beyond 6 and hence the above boundedness property is satisfied. 

It can be shown that if the (symbolic) model checking algorithm in Figure 0 
terminates, we can successfully model check for boundedness (unboundedness) 
properties. It is now natural to ask the question whether the procedure in Figure 
0 is guaranteed to terminate. The answer is ’no’; consider the timed automaton 
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in Figure[2] — the algorithm in Figure |9]will not terminate for this example (an 
infinite sequence of “states” which are not “included” in the “previously” gener- 
ated states are produced) . Of course, the procedure can be forced to terminate 
by including some maximal constant manipulation techniques (as the trim oper- 
ation introduced in | 23| or the extrapolation operation | 12| or the preprocessing 
step m)- But then, like the region graph technique, it can be shown that these 
techniques cannot be directly used for model checking for boundedness prop- 
erties. So the natural thing now would be to develop techniques that force the 
termination of the procedure in Figure E] (in cases where it is possible) but do 
not lose any information with respect to boundedness properties. It is in this 
context that history- dependent eonstraint widenings come into play. 

Before introducing our framework of history-dependent constraint widenings 
(accurate widenings), let us try to see whether the already-existing abstract inter- 
pretation framework m can provide solutions to the problems described above. 
Abstraction interpretation techniques m are useful tools to force termination 
of the symbolic model checking procedures. Here one obtains a semi-test by in- 
troducing abstractions that yield a conservative approximation of the original 
property. Such methods have been successfully applied to many nontrivial exam- 
ples [12I3I24II5] . While these abstractions force the termination of the model 
checking procedure, they sacrifice their accuracy in the process (note that by 
accuracy, we mean not only accuracy with respect to reachability properties, 
but also with respect to boundedness properties). One of the most commonly 
used abstractions is the convex hull abstraction |24I12I8| . 

The application of automated, application independent abstractions that en- 
force termination, as is done in program analysis, to model checking seems dif- 
ficult for the reason that the abstractions are often too rough0. To know the 
accuracy of an abstraction is important both conceptually and pragmatically. 
As Wong-Toi observes in p4| . 



...The approximation algorithm proposed is clearly a heuristic. It would 
be of tremendous value to have analytical arguments for when it would 
perform well, for when it would not.... 



As we saw above, any symbolic model checking procedure that “loses” accuracy 
will not be able to model check for boundedness (unboundedness) properties. 
Hence, in this paper, we propose a framework, to provide a partial answer to the 
question asked by Wong-Toi, viz., to determine automatically (using analytical 
methods) whether an abstraction performs well (does not lose accuracy) in a 
situation and then apply the abstraction. 

We present methods that carry over the advantages of abstract interpreta- 
tion techniques without losing precision. To be more specific, we apply history- 

^ Note the statement of Halbwachs in [Tsj, that “Any widening operator is chosen 
under the assumption that the program behaves regularly. . . . Now the assumption of 
regularity is obviously abusive in one case: when a path in the loop becomes possible 
at step n, the effect of this path is obviously out of the scope of extrapolation 
before step n (since the actions performed on this path have never been taken into 
account). . . ” 
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dependent constraint widening techniques, as already foreseen in flOlTTI . to 
provide an application-independent abstract interpretation framework for model 
checking for timed systems. Basing our intuitions on techniques from Constraint 
Databases [21], we show that abstractions of the model checking fixpoint op- 
erator, through a set of widening rules, can yield an accurate model checking 
procedure. These abstractions are based on syntax of the constraints rather than 
their meaning (the solution space) in contrast with previous approaches (e.g., |3| 
I19I24I4| 1. As we demonstrate on examples, they can drastically reduce the num- 
ber of iterations or even, in some cases, force termination of an otherwise non- 
terminating test. In contrast with the abstract interpretation techniques used 
for program analysis, they do not always force termination; instead their ab- 
straction is accurate. That is, they do not lose information with respect to the 
original property; when they terminate, they provide information which is suffi- 
cient even for model checking for boundedness (unboundedness) properties; i.e., 
in cases where termination is achieved, the abstractions are sound and complete. 
Also, being based on the syntax of the constraints they can be implemented ef- 
ficiently (they do not require computation of the convex hull like |24ldllf)j :b 
We first show toy examples in which our abstractions (henceforth called widen- 
ing rules) either achieve termination in an otherwise non-terminating analysis or 
drastically accelerate the termination of symbolic forward reachability analysisl^ 
We then show the performance of a prototype model checker, implemented using 
the techniques presented in this paper, on some standard benchmark examples 
taken from literature. In the Conclusion, we discuss the generality of our ap- 
proach. The proofs and details are omitted from this extended abstract for lack 
of space. We invite the reader to go through an extended version of this abstract 
available at http://www.mpi-sb.mpg.de/^supratik/mainwide.ps. 



2 Timed Automata, Constraints, and Model Checking 

For the purposes of this paper, we model timed systems using timed automata. 
We refer the reader to j2] for a formal treatment of timed automata. 

We now fix the formal set up of this paper. We use lower case Greek letters 
for a constraint and upper case Greek letters for a set of constraints (which 
stands for their disjunction). The interpretation domain for our constraints is TZ 
the set of reals. We write x for the tuple of variables x\,. . . ,Xn and v for the 
tuple of values Ui, . . . ,u„. As usual, 7?., v ^ is the validity of the formula 
under the valuation v of the variables xi, . . . , x„. We formally define the relation 
denoted by a constraint ip as: 



[p\ = {v\TZ,v \= <p} 

® Note that we consider forward analysis, instead of backward analysis, for the obvious 
advantages mentioned in [18] (Forward analysis is amenable to on-the-fly local model 
checking and also to partial order reductions. These methods ensure that only the 
reachable portion of the state space is explored). Moreover, backward analysis cannot 
be used for model checking for boundedness properties. 
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Note that X\, . . . ^Xn act as the free variables of ip and implicitly all other vari- 
ables are existentially quantified. We write for the constraint obtained by 
alpha-renaming from ip. We define [<P], the relation denoted by a set of constraints 
(p with respect to variables x\,. . . ,Xn in the canonical way. For a constraint (p 
and a set of constraints {tpi, . . . ,tpk}, we write <p [= V^=i i’i ^ Ui=i[V’*]- 

For sets of constraints and <p2 (where by a set of constraints <P = {p>i}, we 
mean \J ^Pi), we write \= 'P2 if for all p G there exists p' G ^2 such that 
[p\ Q [</5^].We write an event (an edge transition or a time transition or a com- 
position of several edge and time transitions) as cond ip action p, where the 
guard '0 is a constraint over x\, ... ,Xn and the action is a constraint over the 
variables Xi, . . . ,Xn and x{, . . . ,x'.^. The primed variable x' denotes the value of 
the variable x in the successor state. Note that we use interleaving semantics 
for our model. We will use a set of constraints ^ to represent a set of 
states 5 if 5 = [^] . The successor of a set of states of such a set with respect 
to an event e = cond ^ action p is represented by the constraints obtained by 
conjoining the guard tp and the action p of each event with each constraint p of 
<P: 

post\e{(l>) = A Ip A p \ p G (1>,TZ \= p A Ip A p} 

where the existential quantifier is over all variables but x'. 

We next formulate possibly non-terminating symbolic model checking pro- 
cedures for boundedness properties, in our constraint-based framework, The 
template for the algorithm is given in Figure [HI Here post{<P) = Ue^sPost\e{(l>) 
where £ is the set of all events of the timed system {simple and compound; see 
below for definitions of compound (composed) events). The algorithm is basi- 
cally a (inflationary) fixpoint computation algorithm. Note that the template 
Symbolic-Boundedness can be used for model checking for the logic Cs [H]. 
Also note that the algorithm is breadth first. In the sequel, we call the algorithm 
Symbolic-Boundedness as the breadth first (symbolic forward) reachability anal- 
ysis algorithm. 

The locations of a timed automaton can be encoded as finite domain con- 
straints (in our algorithms we assume that the locations are encoded as finite 
domain constraints). We denote a position (simply a state) [mi] of the timed 
automaton having location component i as £(v) where v denotes the values of 
the clocks. In general, for a set S of states having the location component £, we 
write (£,S), or {i{x),p), where v? is a constraint and S' =[</?] = {v | £(v) G S}. 
Here the free variables of p are {a;i, . . . , Xn}. In the sequel, we will refer to a set 
of states with location component i and represented by (£{'k),p) as a symbolic 
state or simply a state when it is clear from context. 

3 Widening Rnles 

In this section, we consider how one can achieve (or just speed up) termination 
of the breadth first forward reachability analysis algorithms for boundedness (as 
well as safety) properties. We define widening rules that are accurate i.e., do 
not lose information with respect to the original property. We show that these 
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widening rules can be used to achieve termination in cases where termination 
is not guaranteed in forward analysis. We also show that for some examples for 
which termination of forward analysis but widening can drastically accelerate 
the termination. 

In general, the events considered here may not be an original event but is con- 
structed as a composition of events. We write e = euent(7, ^p) when application 
of the event e to the constraint 7 results in the constraint tp. 

Definition 1 (Compound Events.). Let e\ = cond ^1 action pi, . . . ,ek = 
cond ipk action pk be k original events of the timed system. Assume that the 
source location for the first event and the target location for the last event are the 
same. Assume that the target location for the jth event and the source location 
for the (j + l)st event are same (1 < j < k — 1 ). Also assume that for each event 
6j, each variable Xi and x\ in the guard and action have been alpha-renamed to 
x{ and x{~^^ respectively. Then the compound event (or composed event) corre- 
sponding to Cl, ... ,Ck is given b^ cond true action pAip where pAif is given 
by 

p Aip= (3_{xi,xk+i}</5i Alpi A . . . Apk A ^/>fc)[x,x']. 

See below for examples of compound events. Given that the theory of reals 
with addition and order admits quantifier elimination, pAip can be expressed in 
a conjunctive normal form. For the timed automaton given in Figure [T] the event 
cond true action x' = x -\- z, z > Q,y' = y -\- z,y' <2 is a, simple (time) event 
corresponding to the time transition in location 0 while cond loc = 0 action y' = 
0,x' = x,loc' = 1 is a simple or original (edge) event corresponding to the edge 
from location 0 to 1. 

We consider only non-strict inequalities here. The strict inequalities can be 
dealt with similarly. The template for symbolic boundedness procedure with 
widening is defined in Figure [ 7 | in the Appendix. The function WIDEN is 
defined in Figure |8] in the Appendix. Note that the procedure in Figure [8] is 
based on a breadth-first search. In a call to WIDEN{<Pi,post{(l>i)) one of the 
three widening rules WIDENi, WIDEN2 or WIDEN3 described below is fired 
provided the conditions of that rule are satisfied. If the condition in the WIDEN 
function applies to several decompositions of 7, the corresponding widenings 
are effectuated in several successive iterations. In the sequel, we refer to the 
procedure Symbolic-Boundedness-W as the breadth first forward reachability 
analysis procedure with widening. 

We now illustrate the widening rules with examples. The intuition behind 
the widening rules is as follows: if we can detect from the syntax of a sequence of 
events e and a constraint p, that the sequence p,post\g{p), . . . “grows” infinitely 
in a particular direction (i.e., actually leads to an infinite sequence with respect 
to reachability analysis), we will try to add the union of the sequence to our set 
of reachable states. Thus for widening rule I (for the if part), the syntax of the 

Note that we can construct an event with empty guard as the events 
cond action p and cond true action p A are equivalent with respect to 

symbolic model checking. 
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input constraint {rj Axi — Xj > Cij ) and that of the event {6 Ax' ^ = Xj +x'^AXi < 
Ci which may be a composition of several simple events as described above) 
tells us that this constraint-event combination will generate an infinite behavior 
{•q A Xi — Xj > Cij, q A Xi — Xj > Cij — ct, . . see example below) provided the 
other conditions are satisfied. Hence we infer the limit of this sequence which 
is q (since Cij < 0 and ct > 0) and add it to the set of states. Similar are the 
intuitions behind the other widening rules. 

Consider the example timed automaton in Figure |2] Note that forward 
breadth- first reachability analysis does not terminate. Consider the events 4 and 
3. Event 4 is given by e = cond X 2 < 2 action x '2 = Q,x'i = x\ (we do not 
show the location explicitly) . Event 3 is the time event at location 1 and is given 
by e' = cond true action x'l = xi + z, x '2 = X 2 + z, z > 0 (time increases by 
amount z). We compose transition (sometimes we will use the term ’transition’ 
for ’event’) 4 and transition 3 using the method given above. The resulting 
compound event is ei = cond true action ip A ip where 

If A tp = x'l = Xi + x' 2 , X 2 < 2, 0:2 > 0. 

Now consider the infinite sequence of states produced by a breadth-first 
reachability analysis for this automaton 

(L0(x),a::i = 0 ,X 2 = 0) {L0{x),xi = X 2 ,xi > 0) 

{Ll{x),xi = 0,X2> 0) — ^ {L1{x),x2 — Xi > 0,xi > 0) 

— ^ (Ll(x),0 < Xi < 2 ,X 2 = 0) 

— ^ (Ll(x ), — X 2 > 0 ,X 2 > 0, X 2 — xi > —2) 

(Ll(x),0 < xi < 4:,X2 = 0) 

(Ll(x), xi — X 2 > 0,X2 > 0, X 2 — xi > —4) 

4 ^ 

(in the above we denote location i by Li.) Now see that the state under the 
overbrace along with event ei satisfies the conditions of the widening rule I (the 
if part) defined in FigurelTniin the Appendix {i = 2,j = 1, j = q Ax 2 ~ xi > —2 
where q = Xi — X 2 > 0,X2 > 0, C 21 = —2 and 0 = x '2 > 0 ). Hence, applying the 
widening, we obtain the state (/i(x),xi — X 2 > 0 ,X 2 > 0) (the reader can easily 
make out that if the sequence of transition 4 and transition 3 is repeated infinitely 
many times to the state under the overbrace, the constraint xi — X 2 > 0, X 2 > 0 
will be obtained). After this any state generated is subsumed (included) by 
this state. Hence the breadth first forward reachability analysis with widening 
terminates. 

Before defining widening rule II, let us introduce some notation. Let Afn 
denote {1, . . . , n}. Let / denote a subset of Afn- The widening rule II is defined 
in figure fTTl in the Appendix. 

To show an example in which application of widening rule II forces ter- 
mination, we look at the example in figure |21 Note that breadth-first forward 
reachability analysis does not terminate for this example. The following infinite 
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Fig. 2. Illustrating widening rule I 
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2 

xl=<2 



x2:=0 




5 




Fig. 3. Illustrating widening rule II 



sequence of states is generated in a breadth-first forward reachability analysis 
for this example. 



(L0(x 
1 



= 0 ) 
= 0 ) 



= 0 , = 0 ) 

(L0(x), Xl = X2,X2 > 0) 

(Ll(x),a;i > 0,2:1 < 2,2:2 
(L2(x),2:i > 3,2:1 < 6,2:2 

/ s 

(Ll(x), 2:1 — 2:2 > 3, X2 — xi > —6, 2:2 > 0) 
(Ll(x), xi — X2 > 3, 2:2 — 2:1 > —6, X2 > 0) 
(L2(x), 2:1 > 6, 2:1 < 10, X2 — 0) 

(L2(x), 2:1 — 2:2 > 6, 2:2 — 2:1 > —10, 2:2 > 0) 



(Ll(x), xi — X 2 > 0, 2:2 — 2:1 > —2, X 2 > 0) 
(L2(x), xi — X 2 > 3, 2:2 — 2:1 > —6, 2:2 > 0) 



Now consider the compound event €2 = cond true action ip A il’ obtained by 
composing transitions 3 , 4 , 5 and 6 . Here 

(p A tp = x'l > Xi — X2 + x'2 + 2 A x'l — x'2 < xi — X 2 + ^ A x'l > Xi + x'2 A x'2 > 0 - 

See that the conditions of widening rule II (the if part) are satisfied for 62 
and the state under the overbrace in the sequence {i = 2 , j = 1 , r] = X2 > 0, 
C21 = —6 < 0 , C12 = 3 and 6 = x\ > x\ — X2 + x'2 + 2 , x\ > a:i -I- a;^, 2:2 > 0 ). 
The reader can easily convince herself that the give state and event 62 do not 
satisfy the conditions of widening rule I). Applying the widening, we obtain 
the state (Ll(x),a:i — 2:2 > 3 , 2:2 > 0 ) (viewing the constraint solving involved 
geometrically may provide better intuitions). The states which are further gen- 
erated are subsumed by this state. So breadth- first forward reachability analysis 
with widening terminates after this. Note that in this case, application of ab- 
stract interpretation with the convex hull operator as is done in mm would 
produce the state (Ll(x),2:i — X2 > 0,2:2 > 0 ). This can lead to ’don’t know’ 
answers to certain reachability questions (e.g., consider the reachability question 
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whether the location lA can be reached with the values of the clocks satisfying 
the constraint X\ — X 2 > 2,X2 — X\ > —3, 0:2 > 0). As for the extrapolation 
abstraction [12| , we have already stated in the Introduction that it is unsuitable 
for model checking for boundedness properties. 

In widening rule III we use periodic sets following Boigelot and Wolper . 

The widening rule III is defined in Figure |6]in the Appendix, where the pred- 
icate int(x) is true if and only if a; is a nonnegative integer. Consider the example 
in Figure |4] Note that breadth-first forward reachability analysis does not ter- 
minate for this example. The following infinite sequence of states is generated in 
course of a forward (breadth- first) reachability analysis for this example: 



xi > -l,x2 > 0) 
xi > —5, X2 > 0) 



(Z_0(x), a;i = 0, *2 = 0) 

— ^ (Z_0(x), Xl = X2,X2 > 0) 

2 3 

>■ (Z-l(x), X2 = 0 ,Xl > 0, Xl < 1) > (Z-l(x), Xl — X2 > 0, X2 — 

(Z_2(x), Xl > 4,xi < 5, X 2 = 0) — ^ (Z_2(x), xi — X 2 > 4, X 2 — 

> (Ll(x), Xl — X2 > 4, X2 — Xl > —5, > 0) . . . 



Now we compose transitions 4, 5 and 6. The compound event is 63 = 
cond true action ip A ijj where 

ip A ijj = x'l = Xl + x '2 A x '2 > 0 A X2 = 4. 

It is easy to see that the state under the overbrace in the infinite sequence along 
with event 63 satisfies the conditions of widening rule III {i = 2, j = 1, r] = X 2 A 
0, C12 = 0, C21 = — 1 < 0). Hence, applying widening rule III we get the state 
(Ll(x), > 0, int{k),xi — X 2 > A: * 4, a;2 — > — 1 — fc * 4). The states further 

generated are subsumed by this state. So (breadth-first) forward reachability 
analysis terminates after applying the widening rule. Note that application of 
abstract interpretation with the convex hull operator mm will produce the 
state (Z_l(x),a::i — 2:2 > 0,^2 > 0). Hence for certain reachability questions we 
can get a ’don’t know’ answer. 



1 
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Fig. 4. Illustrating the widening rule III 



Now we show that the widening rules are accurate with respect to bounded- 
ness properties. 

Theorem 1 (Soundness and Completeness). The procedure Symbolic- 
Boundedness- W obtained by abstracting the forward breadth first reachability 
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analysis procedure with widening defined hy the widening rules I, II and III yields 
(if terminating) a full test of boundedness (unboundedness) properties for timed 
systems (modeled by timed automata). 

Note that the above theorem also implies that if the procedure Symbolic- 
Boundedness-W terminates, then one can get a full test of safety properties as 
well. Below we provide effective sufficient conditions for termination of Symbolic- 
Boundedness-W. By a simple path in a timed automaton U, we mean a sequence 
of events Ci . . . where each is an original event of lA and 

— the source location of e^+i is the same as the target location of for 1 < 
i < m — 1, 

— any event with same source and target locations is a time event, 

— for any two edge events and Cj, 1 < i < j < m, the target locations of Ci 
and Cj are different, 

— and if is an (original) time event, then and e^+i are edge events. 

With this definition, there are only a finite number of such simple paths in a 
timed automaton. The simple path p = e\ . . .Cm leads from location to the 
location if there is a the source location of Ci is and the target location of 
Cm is The simple path e\ . . . Cm is a simple cycle if the source location of e\ 
is the same as the target location of e^. Note that there is only a finite number 
of such simple cycles in a timed automaton. 

Theorem 2 (Sufficient Conditions for Termination). Let U be a timed 
automaton and let i be a location in lA such that there is a simple cycle C from 
I to itself and the following three conditions are satisfied. 

— There is a simple path in lA of the form e = cond ip action leading from 
the initial location to £ such with the cycle C along with the constraint 
(3_x'V5*^ a (fi a '0)[x] that satisfies the conditions of the widening rules I, II 
or III where ip^ is the initial constraint. 

— For each original event e! = cond ip' action if' with target location £ that lies 
on a cycle in the control graph oflA, (3_x'i^' A'i/'OM Posftiv) if widening 
rule I or II is satisfied in the previous condition and (3_x'</j' A V’OM H 
post|t (?7 A 3fc > 0 A int{k) A Xi — Xj > Cji + k * Cj A Xj — Xi> Cji — k * Cj) if 
widening rule III is satisfied in the previous eondition, where ij, Cji are as 
in the definition of the widening rules and t is the time event at loeation £. 

— The control graph of lA satisfies the temporal formula AG{true =k 
AF(atJ)) where at A is an atomic proposition satisfied only by loeation 1. 

Then the procedure Symbolic-Boundedness-W terminates forlA. 

It can be seen that the example in Figure [5] satisfies the sufficient conditions 
stated above. 

We have implemented a prototype based on the approach (in the CLP (7?.) 
system of Sicstus Prolog 3.7). The performance shown, so far, by our approach 
has been quite encouraging. We have used our implementation to verify the 
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safety and boundedness properties of several well-known benchmark examples 
taken from literature. The experimental results are summarized in the table 
in Figure O All results are obtained on a PC (200 MHz Pentium Pro). The 
experiments show a marked improvement over the timings obtained without 
using the accurate widening rules in [2^. The timings obtained for Fischer’s 
protocol (two processes), Rail- Road Crossing, and Audio Protocol without using 
the widening rules are 4.2s, 1.8s and 7.2s respectively. All the timings in Figure |5] 
denote the total time taken for reachability analysis. 



Example 


time (seconds) 


Fischer’s Protocol (Two Processes) |22| 


2.1 


Rail-road Crossing 


0.8 


Audio Protocol |20| 


2.3 



Fig. 5. Experimental results 



4 Related Work 

In this paper, we have presented a constraint based framework for symbolic 
model checking of timed systems against boundedness properties. We have shown 
that it is possible to achieve (or just accelerate) termination of our symbolic 
model checking procedure with abstractions by widening that are, as we prove, 
accurate. Our approach allows us to do a full test of the safety and bounded- 
ness (unboundedness) properties without going into the complications of region 
construction. Regarding the generality of our approach, we do not claim that 
the three widening rules described in this paper encompass (i.e., achieves ter- 
mination and/or speed-up of model checking procedure) the full class of timed 
automata. We have provided sufficient conditions under which the procedure 
Symbolic-Unboundedness-W is guaranteed to terminate. However, for several 
examples the procedure terminates even though the sufficient conditions do not 
apply. 

Note that the model checking procedure for Uppaal |S] is also based on seman- 
tics of constraints but their algorithms are based on graph-theoretic techniques 
rather than techniques from constraint programming. We believe that incorpo- 
ration of accurate widening framework in UPPAAL and the other approaches 
mentioned above can significantly speed-up model checking procedures based on 
those approaches. 

Our widening operatoris closely related to Boigelot and Wolper’s loop-first 
technique [5] for deriving periodic sets as representations of infinite sets of inte- 
ger valued states for reachability analysis. As a difference, Boigelot and Wolper 
analyze cycles and nested cycles in the control graph to detect meta-transitions 
before and independently of their forward model checking procedure, whereas we 
construct new events during our model checking procedure and consider them 
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only if we detect that they possibly lead to an infinite loop. Berard’ and Fri- 
bourg use a constraint-based framework for reachability analysis for timed 
Petri nets. They have been able to verify several interesting examples using their 
approach based on meta transitions. Our approach, rooted in the abstract in- 
terpretation framework, is different from theirs in that we accelerate the model 
checking procedure using widening rules based on syntax. 

The application of widening techniques to the verification of systems with 
huge or infinite state spaces has proven useful in several examples. Halbwachs 
et.al. |19| . using linear relational analysis to prove properties for linear hybrid 
systems, defines a widening operator over convex polyhedra: unions of convex 
polyhedra are approximated by their convex hull before the widening step. Ap- 
proximation techniques for more general classes of hybrid systems are studied 
in USTTI . Specifically, Henzinger and Ho [14] apply an extrapolation operator 
which gives better approximations than Halbwachs et. als’ convex widening op- 
erator in their examples. For integer valued systems, abstract interpretation has 
been used effectively in |B]. In [Z], it was explicitly mentioned that one main dif- 
ficulty with the approximate approach is that the abstraction is often too rough. 
We have shown in Section El that our widening techniques will give full test of 
reachability properties for timed systems where the approximate methods |31 
1241 19j would produce a ’don’t know’ answer. Also, in contrast with our accu- 
rate widenings, the widening techniques proposed in [Idl24ll9j cannot be used 
for model checking for boundedness properties. Note that it is not possible to 
find out in most cases, using semantics-based techniques, whether a program 
loop really generates an infinite behavior with respect to reachability analysis. 
Hence, application of widening combined with semantics-based techniques may 
result in loss of accuracy that will render these techniques unsuitable for model 
checking for boundedness properties. It would be interesting to look at how the 
techniques described in this paper extend to more general classes of hybrid sys- 
tems. The general goal will be a whole library of accurate widening rules for a 
variety of verification problems. 
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Function W IDEN^{'y,ip') 

( = g A Xi — Xj > Cij A Xj — Xi > cji 

(p A Ip = 6 A x'i = Xi -\- x'j A Xj = Cj 



if < 



Cij < 0 
Ci > 0 



Cji > Cij 

[ r;[x'] 1= (3 _x'(?7 A ip A ip)) A A Xi — Xj > dj A xj — Xi> cji Axj = Cj) 

return jy A 3fc > 0 A int{k) Axi — Xj > Cji 3- fc * c j A Xj — Xi> Cji — k* Cj 
else return p' 



Fig. 6. Widening Rule III 



Procedure Symbolic-Boundedness-W {L>) 

Input A set of constraints 

Output A set of constraints representing sets of states reachable from \L>] 

<L>o := <L>. 

repeat 

begin 

<?,+! ^L>iC WIDEN{<L>i,post{L'i)) 

end 

until \= L>i. 
return <Li. 

Fig. 7. Template for Model Checking for Boundedness Properties with Widening 
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Function WIDEN{r, <P) = {WIDENij, ip) \ y e E,ip e <P} 
Function W IDEN{y, p) 
ifi WIDENi{j,(fi) 

If ifi ^ ip return pi 
else {pi := W IDEN^i'y ,p) 

If pi ^ p return pi 
else pi := W I DEN 2 ,{'y ,p)} 
return pi 



Fig. 8. Widen Function 



Procedure Symbolic-Boundedness(^) 

Input A set of constraints $ 

Output A set of constraints representing sets of states reachable from [#] 
$0 ■= 

repeat 

begin 

^i+i = <Pi Upost{<Pi) 

end 

until <Pi+i ^ <Pi. 
return $i. 

Fig. 9. Template for Model Checking for Boundedness Properties 
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Function WIDENi{'y,ip') 

{ ^ = r) /\Xi — Xj >Cij 

ip A tp = 6 A x'j = Xj + x'i A Xi < Ci 

Cij < 0 
Ci > 0 

?y[x'] 1= (3 _x'(?7 Ap a tp)) A (B-x'fi' A Xi — Xj > dj AXi < a) 

{ -y = r] A Xi — Xj > Cij A Xi < a 
ip A p) = 6 A x'j = Xj + x'i 

Cij < 0 
Ci > 0 

rilx'] \= (3_x'(?7 Ap a Ip)) A (3_x'0 AXi — Xj > dj AXi < a) 
return rj 
else return p' 



Fig. 10. Widening Rule I 



Function WIDEN2{'y,p') 

' -y = ri A Xi — Xj > dj A Xj — Xi > Cji 
p A Ip = 9 A Xj — x'i < Xj — Xi + ttji 

dj < 0 
if ttji > 0 

(3_x'(p Alp A r]) A (3_x'6* A Xi — Xj > dj A Xj — Xi > Cji) = ( A Xj 
rilx'] 1= C 

0 ^ Cjj ^ Cjj 

return 7] AXj — Xi > Cji 

{ 1 = 9^ Ai,j,ei ~ 

pAip = 9 A Aij,6/ Xj - Xi < Xj - Xi + Uji 

Cij < 0 
Ojji ^ 0 

N (3_x'V5 A %pAri)A (3_x'6» A Ai,i,e/ Xi - Xj > dj) 

return rj. 
else return p' 



Fig. 11. Widening Rule II 
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Abstract. For most applications of first-order theorem provers a proof 
should be found within a fixed time limit. When the time limit is set, 
systems can perform much better by using algorithms other than the 
ordinary complete ones. In this paper we describe the Limited Resource 
Strategy intended to improve performance of resolution- and paramo- 
dulation-based provers when a fixed limit is imposed on the time of a 
run. We give experimental evidence that the Limited Resource Strategy 
gives a significant improvement over the OTTER saturation algorithm, 
algorithms not using passive clauses for simplification and the weight- 
based algorithms. 



1 Reasoning with Limited Resources 

First-order theorem provers (in the sequel simply provers) have a number of 
applications. The main application areas for provers are software and hardware 
verification, computer algebra and assisting human mathematicians. In nearly 
all applications, provers are used in the following way. When a prover is run on a 
goal, a time limit is set. If neither proof nor countermodel could be found within 
the time limit, the prover terminates. Then the goal can be reconsidered, for 
example by formulating intermediate statements (lemmas) or by providing some 
inference steps interactively, and the proof-search continues on the new goals or 
using the lemmas. 

Since first-order logic is undecidable, any complete prover is potentially non- 
terminating. Therefore setting a time limit for processing a particular goal is a 
natural idea. Moreover, for most applications it is difficult to expect human users 
or systems ready to wait for an answer forever. This paper addresses the problem 
of reasoning in limited time. It turns out that when the time is limited, systems 
can perform much better by using algorithms other than ordinary complete 
ones. In this paper we describe the so-called Limited Resource Strategy (LRS) 
implemented in our system Vampire [10,9], discuss its advantages and drawbacks, 
compare it with the strategies so far used in Vampire and other systems and 
describe experiments carried out over a number of first-order problems. 

2 Saturation-Based Theorem Proving 

The fastest first-order theorem provers of the last two CASC competitions [13] 
(with one exception of Setheo [7]) use saturation algorithms. There exist two 
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main kinds of saturation algorithms, one was implemented in OTTER [6] and 
its predecessors (an overview of these early provers can be found in [5]), another 
one was used for the first time in DISCOUNT [1]. In this section we describe 
these saturation algorithms. For simplicity, we will call them the OTTER and the 
DISCOUNT algorithms, respectively. The OTTER algorithm is implemented at 
least in OTTER, Gandalf [14], SPASS [16], and Vampire, and the DISCOUNT 
algorithm is implemented at least in DISCOUNT, E [11], SPASS, Vampire and 
Waldmeister [4]. 

Unfortunately, the terminology related to saturation algorithms used in dif- 
ferent research groups varies a lot, so no standard terminology exists. Let us 
develop some relevant terminology. Saturation algorithms used in first-order the- 
orem provers operate on clauses. For each new clause generated by an inference 
the prover decides whether this clause should be kept or discarded. The set of 
kept clauses may be huge, so most of the systems perform inferences not on 
all kept clauses, but only on a subset of them. The clauses in this subset, i.e. 
those used for inferences will be called active. All other kept clauses are passive 
(though as we will see passive clauses can also participate in inferences, but of 
a special kind). 

The two different saturation algorithms differ in their treatment of passive 
clauses. In the DISCOUNT algorithm passive clauses never participate in infer- 
ences or simplifications. In the OTTER algorithm passive clauses can participate 
in simplifications, for example rewriting by unit equalities or subsumption. 

2.1 The OTTER Saturation Algorithm 

Let us begin with the OTTER algorithm which is shown in Figure 1. It is 
parametrized by several procedures explained below: 

— select is the clause selection function. It decides which passive clause should 
be selected for activation. 

— infer is the function that performs inferences between the current clause 
current and the set of active clauses active. This function returns the set of 
clauses obtained by all such possible inferences. This function varies from 
system to system. Usually, infer applies inferences in some complete infer- 
ence system of resolution with paramodulation. 

— simplify {set, by) is a procedure that performs simplification. It deletes re- 
dundant clauses from set and simplifies some clauses in set using the clauses 
in by. To preserve completeness, the simplified clauses are always moved to 
passive. Typically, deleted clauses include tautologies and those clauses sub- 
sumed by clauses in by. A typical example of simplification is rewriting by 
unit equalities in by. 

— Likewise, inner simplify simplifies clauses in new using other clauses in new. 

When we simplify new using the clauses in active U passive, we speak of 
forward simplification, when we simplify active and passive using the clauses in 
new, we speak of backward simplification. 

Typical behaviour of this algorithm is quantitatively characterised by the 
following empirical observation: in a matter of seconds the total number of kept 
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input: init : set of clauses ; 
var active, passive, new : sets of clauses ; 
var current : clause ; 
active : = 0 ; 
passive := init ; 
while passive ^ 0 do 
current := select(passive) ; 
passive := passive — {current} ; 
active : = active U { current} ; 
new : = inf er {current, aetive) ; 
if goal _found {new) then return provable ; 
inner _simplify {new) ; 
simplify {new , active U passive) ; 
if goal _found {new) then return provable ; 
simplify {aetive, new) ; 
simplify {passive, new) ; 

if goaLfound{active U passive) then return provable ; 
passive : = passive U new 

od ; 

return unprovable 



Fig. 1. The OTTER Saturation Algorithm 



clauses gets very big, whereas the share of the active clauses is small and keeps 
decreasing. To illustrate this, we provide statistics on an unsuccessful run of 
Vampire with the time limit of 1 minute on the TPTP problem ANA003-1. Dur- 
ing this run, 261,573 clauses were generated. The overall number of active clauses 
was 1,967, the overall number of passive clauses 236,389. The clauses generated 
in this run contain function symbols and equality, many of the clauses have a 
large number of literals and/or heavy terms. It was possible to process such a 
large number of clauses in one minute due to success of the modern indexing 
techniques [3,8]. Even when the state-of-the-art indexing techniques are used, it 
is very difficult to manage clause sets containing over 100, 000 clauses efficiently. 
As a consequence, when theorem provers are used for practical applications, 
completeness is often compromised in favour of efficiency: the provers discard 
clauses that may be nonredundant. 



2.2 The DISCOUNT Saturation Algorithm 

It was observed that usually the total number of active clauses in the OTTER 
algorithm is considerably less than the number of passive clauses. Meanwhile, 
simplification of and by the passive clauses consumes significant amount of time. 
One can modify the OTTER saturation algorithm in such a way that passive 
clauses never participate in simplifications. Such a modified saturation algorithm 
will be called the DISCOUNT algorithm in this paper. The algorithm is shown 
in Figure 2. 
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input: init : set of clauses ; 
var active, passive, new : sets of clauses ; 
var current : clause ; 
active : = 0 ; 
passive := init ; 
while passive ^ 0 do 
current := select(passive) ; 
passive := passive — {current} ; 
simplify {{current} , active) ; 

if current is simplified to a goal return provable 
if current is not simplified to a tautology 

then do 

simplify {active, {current}) ; 

if goal_found{active) then return provable ; 

active := active U {current} ; 

new := infer {current, active) ; 

if goaLfound{new) then return provable ; 

simplify {new, active) ; 

passive : = passive U new 




return unprovable 



Fig. 2. The DISCOUNT Saturation Algorithm 



Compared to the OTTER saturation algorithm, this algorithm has the fol- 
lowing features: 

— The new clauses are forward simplified by the active clauses only, the passive 
clauses don not take part in this. 

— Neither active nor passive clauses are backward simplified by the retained 
new clauses. 

— After selection of the current clause it is simplified again by the active clauses 
and then is itself used to simplify the active clauses. Again, the passive 
clauses are not affected. 

If we assume that the overall number of kept clauses is significantly larger 
than the number of used ones, this algorithm involves less computation for the 
same number of active clauses than the OTTER algorithm. However, this al- 
gorithm has a severe weakness: It performs a very limited amount of backward 
simplification steps compared to the OTTER algorithm. This sometimes results 
in the following effect: finding some proofs that are quickly found by the OT- 
TER algorithm involving backward simplification, is now delayed significantly. 
To illustrate this, consider a simple example. Suppose that a, b are constants and 
generated are two unit clauses t = a and t = b with a heavy term t. Since most 
provers try to select lighter clauses (with fewer function symbols), it may take a 
long time before these clauses both appear among the active ones. Rewriting the 
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latter clause by the former one gives a very light clause a = h which is very likely 
to contribute to a derivation of the empty clause. This simplification from t = a 
into t = b will be discovered by the OTTER algorithm as soon as both t = a and 
t = b have been generated, but it may take a long time before they get selected 
by the DISCOUNT algorithm. The same applies for other selection criteria, for 
example when older clauses are preferred to younger ones, since t = a and t = b 
can as well be younger clauses, so their selection will be delayed. 

It was observed experimentally that the time spent for storing and retrieving 
passive clauses in the DISCOUNT algorithm is negligible compared to the overall 
runtime. Therefore, one cannot expect to improve considerably the performance 
of the DISCOUNT algorithm by, e.g. trying to discard some passive clauses when 
a time limit is set (though it can save a lot of memory) . 



3 Reasoning in Limited Time by the OTTER Algorithm 

Growth of the number of kept clauses in the OTTER algorithm causes fast de- 
terioration of the rate of processing of active clauses. Thus, when a complete 
procedure based on the OTTER algorithm is used, even passive clauses with 
high selection priority often have to wait very long before they contribute to 
the search. In the provers based on the OTTER algorithm, all solutions to the 
completeness-versus-efficiency problem are based on the same idea: some nonre- 
dundant clauses are discarded from the clause sets active, passive, or new. 

In this section we explain several approaches to discarding clauses imple- 
mented in the state-of-the-art provers and analyse their main advantages and 
disadvantages. 



3.1 Weight Limit Strategy 

The Weight Limit Strategy was implemented already in the very first versions 
of OTTER. The idea is to set a limit W on the weight of clauses. The weight 
of a clause is a measure reflecting its complexity, for example the number of 
symbols in it. All new clauses with the weight greater than W are discarded. 
This Weight Limit Strategy is especially helpful for interactive use and solving 
difficult problems. The user specifies an arbitrary weight limit, runs the prover 
on a goal, and studies the output. If a proof was not found, the weight limit 
can be changed. Weight Limit Strategy is not very useful for fully automatic 
theorem proving. Since problems submitted to provers are of very diverse nature, 
the useful weight limits can vary. When the weight limit is too high, there is 
essentially no difference between a complete algorithm and a weight-limit based 
one. When the weight limit is too small, a proof with the given weight limit may 
not exist at all, even when a complete algorithm will easily find a proof. Another 
problem with the weight limit was observed by the authors in case studies: for 
many problems heavy clauses are needed for a very short time in the beginning 
of the proof-search, and then only very light clauses suffice for finding a proof. 
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3.2 Incremental Weight Limit Strategy 

However, since light clauses experimentally proved to be very useful, the Weight 
Limit Strategy is very appealing. Several provers, including Gandalf [14], Bliksem 
[2] and Fiesta adopted the Incremental Weight Limit Strategy. The idea of this 
strategy is that the weight limit is initially set to a small value. If no proof is 
found with this small value, the weight limit is increased, and the proof search 
begins either from scratch or using the short clauses obtained during the previous 
run. This strategy is very efficient on quite a number of problems, but also very 
inefficient on many problems. There are two kinds of problems on which the 
strategy behaves poorly. 

1 . Suppose that W is the minimal weight sufficient to find a proof of a problem 
by the prover’s inference system. If the proof search for the weight IF — 1 is 
too costly, the prover will not increment the weight to W, spending all its 
time on smaller weights. 

2. When heavy clauses are only needed in the beginning of proof-search, the 
strategy is inefficient, since it will generate and store heavy clauses when it 
is no more necessary. 

3.3 Memory Limit Strategy 

This strategy was implemented for the first time in OTTER. The idea is as 
follows. Some memory limit is set in advance. When ^ of the available memory 
has been filled, OTTER assigns new weight limit which is calculated in such a 
way that 5% of passive clauses have smaller weight than the limit. From then on, 
this recalculation of weight limit is performed after processing every 10 selected 
clauses. 

This strategy has its own disadvantages. The main problem is that the use 
of memory and the time are loosely connected. If a complete algorithm is run 
by Vampire, the memory used in 1 minute can vary as much as between 20 and 
400 megabytes on a computer with the 400MHz Pentium processor. Setting too 
low memory limit will make a prover terminate before the time limit because all 
clauses needed for finding a proof have been discarded. This effect was indeed 
observed in some previous versions of OTTER intended for the CASC compe- 
titions. For example, in the experiments presented in [15] OTTER terminates 
before the time limit without finding a proof on a number of problems, in the 
worst case in less than 2 minutes when the time limit was 30 minutes. Setting 
too high a limit results in considerable slowdown, since then the system behaves 
as poorly as based on a complete algorithm. 

4 Limited Resource Strategy 

The main idea of the Limited Resource Strategy is the following. The prover tries 
to identify which clauses in passive and new have no chance to be processed by 
the time limit at all, and discards these clauses. Such clauses will be called un- 
reachable. Note that the notion of unreachable clauses is fundamentally different 
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from the notions of redundant ones: redundant clauses are those that can be 
discarded without compromising completeness at all, the notion of unreachable 
clauses makes sense only in the context of reasoning with limited resources. How 
can one identify unreachable clauses? 

When the system starts a proof search on a problem, it is also given a time 
limit t as an argument. The system keeps track of statistics on the use of re- 
sources during the proof search. The main resource measure is the average time 
spent by processing each clause selected as current. Note that usually this time 
increases because the sets active and passive are growing {new is usually rel- 
atively small), so the operations infer and simplify take more and more time. 
From time to time the system tries to estimate how the proof search statistics 
would develop towards the time limit and, based on this estimation, identify 
unreachable clauses. 

The main requirements we imposed on the implementation are the following. 

Requirement 1. Vampire with LRS should be at least as fast as Vampire using 
the complete algorithm. 

Requirement 2. A proof should not be lost when the time limit is set to an 
acceptable value. This means roughly the following. Suppose that Vampire with 
a time limit ti has found a proof in time ^2 < ti. Then Vampire with the time 
limit t 2 should find a proof as well. In other terms, when the time limit is set to 
t 2 no reachable clause should be lost. 

These requirements can be easily satisfied when no clause is identified as 
unreachable, i.e. by using a complete algorithm. So we have a third requirement 

Requirement 3. As many unreachable clauses as possible should be identified as 
unreachable by Vampire. 

Requirement 3 is in conflict with Requirement 2, because the exact estimation 
of which clauses are unreachable is essentially impossible. 

To give the reader an idea how an estimation of unreachable clauses can be 
done, we give a simple example. Suppose that p clauses have been processed 
as current in t seconds, i.e. p/t clauses per second, and I is the current time 
limit. If we assume that the proof search will develop at the same pace, in total 
p ■ l/t clauses will be processed by the end of the time limit. So if the number 
of currently kept clauses k is greater than p ■ l/t, then k — p ■ l/t clauses can 
be discarded. Of course this estimation may be inaccurate, because the time for 
processing one clause as current will most likely increase. To avoid too big errors, 
the estimation of p/t must be done frequently enough. In our experiments the 
estimation was performed after every 500 inferences produced. 

The next question is which k — p ■ l/t clauses should be discarded. The an- 
swer can be obtained by applying Requirement 2. One of the consequences of 
this principle is that no clause processed by the time limit by the complete strat- 
egy should be discarded. But the clause selection in the complete algorithm is 
controlled by the function select, so to identify potentially unreachable clauses 
let us look deeper at the clause selection function. 

All modern theorem provers maintain one or more priority queues. Clauses 
are picked from the priority queues using some ratios. By far the most popular 
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design is based on two priority queues: the age priority queue gives higher priority 
to older clauses, the weight priority queue to lighter clauses. The rational behind 
this strategy is based on the following observation: light clauses are easy to 
process and most likely to contribute to a derivation of the empty clause, but 
discarding an old clause is more likely to turn an unsatisfiable set of clauses into 
a satisfiable one than for a younger clause. The system uses a ratio to decide 
how often the first clause in each queue should be selected. This ratio is called 
the pick-given ratio in OTTER’s manual [6], we will call it the age-weight ratio. 
For example, if the age-weight ratio is 1:4, then out of each 5 selected clauses 1 
will be taken from the age priority queue and 4 from the weight priority queue. 
This strategy was introduced for the first time in OTTER and then used by a 
number of systems, including at least OTTER, Vampire, and Waldmeister [4]. 

Assume that our clause selection function is based on the age-weight queue 
design with age-weight ratio a : w, which means that out of any a -\- w clauses 
a will be selected from the age queue and w from the weight queue. We have 
decided that p ■ {l/t — 1) = p ■ {I — t)/t currently passive clauses can still be 
processed within the time limit. Of these clauses a ■ p ■ {I — t)/{t ■ {a -\- w)) will 
be selected from the age priority queue and w ■ p ■ {I — t)/{t ■ (a -I- w)) from the 
weight priority queue. So Vampire implements a deletion algorithm that discards 
clauses according to these formulas. 

This example shows that LRS can delete many unreachable clauses from 
passive, but it does not demonstrate the full power of the strategy. We will now 
show that the strategy can have a drastic influence on the way the sets new and 
active are processed. This effect is due to the following observation. Suppose that 
the strategy discarded some clauses, and the maximal weight of the remaining 
clauses is W. Suppose a new clause C obtained by an inference has a weight 
W > W. We claim this clause is unreachable. Indeed, C cannot be inserted in 
the reachable part of the weight priority queue. In addition, C is younger than 
any clause in passive. Thus, it cannot be in the reachable part of the age priority 
queue. So C is unreachable. This means that any future clause with the weight 
> W can be discarded, so we can set the limit on the weight to be IT — 1 . (Note 
that this limit can go down as soon as the inference process slows down or more 
clauses with weights less than IT are kept). 

Apart from using the dynamically changing weight limit IT for discarding 
new clauses, we can also use the weight limit to discard some kept clauses. In 
order to discard a kept clause we have to be sure that any inference with this 
clause as a parent gives a clause with a weight exceeding IT. Resolution-based 
provers use calculi based on ordered resolution with negative selection. A typical 
inference rule in such a calculus is ordered resolution with negative selection: 

Ay C D , 

{CyD)9 

where 0 is a most general unifier of A and B, the atom AO is maximal in the 
clause {A V C)9 and is a literal selected in the clause -•B V D. The clause 
(C V D)9 is called a resolvent of the clauses Ay C and ~^B V D. 

When this rule is applied, the nonmaximal part oi Ay C will always be part 
of the clause C y D. Likewise, the non-selected part of -•B V D will be part of 
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CV D. It follows that CVD is always at least as heavy as the nonmaximal part of 
AvC or the nonselected part of ~'B\/ D. The application of the substitution 6 to 
CV D yields a clause at least as heavy as CV D (unless we factor equal literals) . 
Suppose now that we perform a resolution inference with the clause A V C. If the 
weight of C is greater than the weight limit, then any clause inferred from AvC 
would be too heavy. Therefore, Ay C can be discarded from the search space 
because it cannot produce a reachable clause. To implement this, when LRS 
reduces the weight limit, we can search through the whole set passive U active 
for clauses whose nonmaximal (nonselected) part has a weight greater than W 
and discard them. 

When the weight of C does not exceed W we can sometimes simply compute 
the weight of C9. For example, if we have found the substitution 9 together with 
a sufficiently big set of clauses containing the literal ^A9, it still might be useful 
to compute the weight oiC9 and compare it with W in attempt to avoid building 
all the inferences. Moreover, to estimate weight of C9 it is often sufficient to have 
9 constructed only partially. This can be done, for example, when retrieval of 
literals unifiable with -<A is being performed in an index, in which case we can 
identify a branch in the index that does not have to be inspected. 

5 Comparison of LRS with Other Approaches 

The main feature of LRS over other algorithms is the possibility to adapt to 
a particular problem based on the runtime information about the proof-search 
process. No previous knowledge about the problem is needed. In this section 
we briefly explain some advantages of LRS as compared to other existing ap- 
proaches. 

Weight-limit based approaches. Setting a particular weight limit in the beginning 
of proof-search can hardly be helpful since the weight limit needed to solve an 
unknown problem can not be calculated a priori. So we only compare LRS with 
the Incremental Weight Limit Strategy. This strategy has several well-known 
pitfalls. Suppose that the strategy is applied to a problem for which the minimal 
weight limit sufficient to solve the problem is W . 

— For some problems, the proof-search with weight limits smaller than W can 
consume more time than the time limit, while setting the limit to W would 
solve the problem almost immediately. For such problems the Incremental 
Weight Limit Strategy is likely to be much less efficient than the complete 
strategy. 

— For some problems, clauses with the weight W are only needed very early in 
the proof-search, and then clauses with weights less than or equal to some 
W' < W will suffice. If too many clauses with the weights between W' and 
W are generated, the strategy can spend too much time on processing these 
clauses and will fail to find a proof. 

The Limited Resource strategy is immune to both kinds of problems. For the 
first kind of problems, LRS will behave like a complete algorithm, since early in 
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the proof-search LRS behaves like a complete strategy. For the second kind of 
problems, when LRS discovers that clauses of the weights between W' and W 
are unreachable, it will discard these clauses. 

The DISCOUNT algorithm. The DISCOUNT algorithm behaves poorly for 
problems which require many backward simplification steps. Backward simpli- 
fication steps are performed only when the simplifying clause becomes active. 
As a consequence, sometimes the algorithm cannot find proofs easily found by 
other strategies, especially when the proofs contain simplification steps between 
heavy clauses. 

Shortcomings of LRS. Ideally, the requirements for LRS guarantee that it should 
not lose proofs found by a complete strategy. In reality, mistakes in calculating 
unreachable clauses are unavoidable, so in practice on some problems the com- 
plete algorithm beats LRS. 

The main reason for miscalculating reachability of clauses is backward sim- 
plifications. When an LRS-based algorithm discards clauses beyond the dynam- 
ically set weight limit, it is possible that a simplification of a discarded clause 
would result in a short proof. 

However, our experiments carried out over a large number of problems 
demonstrate that on the average the performance of the LRS-based algorithm 
is superior to other algorithms. 



6 Experimental Comparison of the DISCOUNT 
Algorithm and the LRS-Based Algorithm 

To compare the LRS-based algorithm with the DISCOUNT algorithm, we im- 
plemented the DISCOUNT algorithm in Vampire and made a number of exper- 
iments on two benchmarks suites: (i) all 3340 clausal problems in TPTP, (ii) 
the 1836 problems from the list software reuse application (see [12]). On each 
problem. Vampire was run with 3 different literal selection functions using the 
DISCOUNT algorithm, and with the same 3 different selection functions using 
the LRS-based algorithm. The time limit for each run was set to 60 seconds. We 
used a computer with the 450 MHz Pentium processor. Therefore, altogether 
we compared the two algorithms on 15,528 tests. The comparison is fair for the 
following reason. Both algorithm used the same computer, algorithms, datas- 
tructures, and memory management. The only difference was on the top-level 
loop. 

To summarise the results, we consider only so-called interesting tests. Intu- 
itively, a test is interesting if it is neither too easy nor too difficult. Formally, 
we consider the following criterion. A test is interesting if one of the following 
conditions is satisfied: 

1. exactly one of the two algorithms solved the problem; or 

2. both algorithms solved the problem, and at least one of them spent more 
than 10 seconds on it. 
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The results are presented in Figure 3. In this figure we use the following notation: 

-I— 1-: the problem was solved only by the LRS-based algorithm; 

-I-: the problem was solved by both algorithms, but the LRS-based one was at 
least 10 seconds faster; 

=: the problem was solved by both algorithms, and the difference in the solution 
times is less than 10 seconds; 

— : the problem was solved by both algorithms, but the LRS-based one was at 
least 10 slower faster; 

: the problem was solved only by the discount algorithm. 

Of 1726 interesting benchmarks, 1492 were solved by the LRS-based algo- 
rithm, and 1045 by the DISCOUNT algorithm. If these experiments were carried 
out as part of an interactive verification proof, a significant amount of time would 
have been saved by using the LRS-based algorithm. 

7 Experimental Comparison of the OTTER Algorithm 
with and without LRS 

We compared the OTTER algorithm with and without LRS using the same 
benchmark suites as in the previous section. The results are shown in Figure 4. 
Of 1318 interesting benchmarks, 1267 were solved by the LRS-based algorithm, 
and 589 by the standard OTTER algorithm. 

To illustrate how LRS influences the proof-search statistics in terms of the 
share of active clauses in the kept clauses, consider the TPTP problem ANA003- 
1. This problem was solved by no algorithm. The following table summarises the 
total number of used and kept clauses. 

DISCOUNT OTTER LRS 
used 8A9l 1,967 42,050 

kept 1,473,106 236,389 51,751 

The DISCOUNT algorithm could process about 4 times more active clauses 
than the OTTER algorithm. However, it comes at a price of not performing 
some simplification steps. Also, the DISCOUNT algorithm kept about 6 times 
more clauses than the OTTER algorithm since it could not recognise that some 
of them are redundant w.r.t. passive clauses. The LRS-based algorithm could 
process about 21 times more active clauses than the OTTER algorithm and 
about 4 times more than the DISCOUNT algorithm. The small difference be- 
tween the numbers of the kept and the active clauses shows that the calculations 
of reachable clauses made by LRS were quite precise. 

8 Comparing LRS with Weight-Limit Based Approaches 

To compare the LRS with weight-limit based approaches, we experimented with 
the 75 problems from the CASC-16 competition in the MIX division. The prob- 
lems were run with the time limit of 5 minutes on a computer with a SPARC 233 
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MHz processor. We compare the results obtained by Vampire using the following 
strategies based on the OTTER algorithm: LRS, four different fixed weight lim- 
its (50, 40, 30, 20) and Incremental Weight Limit (wine). Only those 51 problems 
for which a proof was found by at least one strategy are considered. In the table 
below we give the total number of problems solved by each strategy. 

strategy LRS 50 40 30 20 wine 
solved 48 45 36 27 21 33 

As it can be seen from the results, the Limited Resource Strategy solves 
more problems than the Incremental Weight Limit Strategy or any strategy 
using fixed weight limit, even when the values of the weight limit are optimal 
for this benchmark suite. There is a problem that could only be solved by LRS 
(ANA002-4), and for 3 more problems the time obtained by this strategy was 
considerably better than by any other strategy. LRS also gives better average 
time than the strategy with weight limit 50, when they are compared on problems 
solved by both of them. 
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Abstract. Within verification of distributed Abstract State Machines 
one often has to prove properties related to the state transition level 
induced by partially ordered runs. This paper shows how such a transi- 
tion level in form of a transition graph may be constructed. In this way 
the verification can be carried out directly on the transition graph. The 
construction itself is given as a sequential non-deterministic ASM. 



1 Introduction 

Distributed ASMs represent a general mathematical model of concurrent com- 
putation. In particular its notion of partially ordered runs allows as much con- 
currency as logically possible. Distributed ASMs have been used successfully 
to specify and verify distributed algorithms including the Bakery Algorithm of 
Lamport [ll5j and the termination detection algorithm of Dijkstra, Feijen and 
van Gasteren [^. Distributed ASMs have also been used to define formal se- 
mantics for several programming (specification) languages like C [4], and more 
recently SDL |^. 

The notion of partially ordered run is a general and adequate description 
of distributed computations. However, in the ASM literature often the use of 
partially ordered runs is avoided. We believe one reason for this can be found in 
the more complex structure of partially ordered runs. For example, in a partially 
ordered run a move is executed in several states. In general there exists no unique 
global state in which a move is executed. This makes verification somewhat 
difficult. 

In order to overcome these problems and make the handling of partially 
ordered runs more feasible the notion of maximal transition graph is introduced. 
A maximal transition graph can be seen as a general description of all possible 
behaviors and can be constructed in an intuitive way. In a certain sense, the 
maximal transition graph contains all partially ordered runs. It can be used 
within the verification process to compare different runs or to reason about a 
single run. Some central concepts like indisputable terms, pre- and post-states 
of a move within a partially ordered run (cf. j^) can be analyzed in the maximal 
transition graph. We believe, that the use of these kind of graphs eases the 
process of verification. The concept of maximal transition graphs is illustrated 
by some examples. 



D. Bj0rner, M. Broy, and A. Zamulin (Eds.): PSI 2001, LNCS 2244, pp. 109-|14^ 2001. 
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The rest of the paper is organized as follows: In section [2| we give a short 
introduction to distributed ASMs. In section |3] we describe maximal transition 
graphs and show some of their advantages. 

2 Abstract State Machines 

We presume the reader to be familiar with We just give a brief introduction 
into the concept of distributed ASMs. An ASM possesses a collection of states. 
A state can be transformed into another state by actions of agents. The relative 
ordering of actions is given by partially ordered runs. 

2.1 States 

States are basically first-order structures which contain functions and relations 
defined over a base set. States of an ASM have the same base set. The vocabulary 
associated with an ASM A is denoted by Voc{A). Beside function or relation 
names a vocabulary contains declaration which are associated with names. The 
collection of states of A is denoted by State (M) . In the following we will not dis- 
tinguish between names and their interpretations in states. External functions 
are completely under control of the external agents which represent the environ- 
ment. In this paper we make use of internal functions only. For more information 
on ASM refer to |7I8J . 

2.2 Actions 

Actions are specified by programs which are associated with agents. We distin- 
guish between internal agents, which can change internal functions (or locations) 
and posses a program, and external agents, which can change external functions 
(or locations) only. A mathematical treatment of actions seen as special equiva- 
lence classes on update sets can be found in [7j. 

2.3 Runs 

A partially ordered run p of A can be defined as a tuple (M, <, A, cr) satisfying 
the following conditions: 

1. (M, <) is a partial ordering such that each segment w.r.t.< induced by an 
element of M is finite. 

2. A : M — >■ Agent{A) is a function such that for each agent a the set {a; : 
A{x) = a} is linearly ordered w.r.t. <. 

3. cr : FinSeg{M, <) — >• State{A), where FinSeg{M,<) denotes the set of all 
finite initial segments of (M, <). cr(0) is an initial state of A. 

4. The coherence condition: If y is a maximal element in a finite initial segment 
Y of (M, <) and X = Y \ {y}, then A(y) is an agent in cr{X), y is a move 
of A(y) and (t{Y) is obtained from a{X) by performing y at cr{X). 
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The collection of all partially ordered runs of A is denoted by ParOrdRun{A). 
Let p = {M, <, A, a) G ParOrdRun{A) be a partially ordered run. The set of all 
finite initial segments of p is denoted by FinSeg{p). Following |5] let Post{t) be 
the set of all finite initial segments in which a move t G M is maximal called post- 
segments. For each I G Post{t), the state a{I) is the state obtained when A{t) 
performs its action in the state a{I \ {t}). Let Pre{t) := {I \ I = J \ {t}, J G 
Post{t)} be the set of all pre-segments. Let PostState{t) denote the set of all 
states that are associated with the post-segments of t, called post-states of t. 
Analogously, let PreState(t) denote all pre-states of t. 

3 Maximal Transition Graph 

In this section we introduce the notion of maximal transition graph. In the fol- 
lowing let A be a distributed deterministic ASM without environment (external 
agents). Furthermore we assume only infinite runs and a fixed set of agents. 

3.1 Motivation 

The maximal transition graph associated with A represent all possible behaviors 
on states. It can be used to analyze partially ordered runs. Due to its intuitive 
representation as a graph, it can be used within the verification of properties for 
partially ordered runs. Each partially run can be found within the maximal tran- 
sition graph. In this way a comparison between partially ordered runs becomes 
more feasible. 

Starting from the initial states all possible next states are related by an edge 
labeled with a name indicating the corresponding executing agent. In order to 
avoid ’cycles’ between states we use a kind of ranking which excludes edges from 
higher to lower ranked states. We start with a simple example. 

Example 1. We consider a distributed ASM A with a static set of internal agents 
a, b. Agent a increments x, agent b increments j/, where x, y denotes constants of 
type Nat where Nat is interpreted within states as the set of natural numbers. 
Initially x = y = 0 holds. There are no external agents. 

a: X : = X + 1 
b; y := y + 1 

In figure [T| (for simplicity ranking is not shown) one can see parts of the maximal 
transition graph associated with ASM A. Consider the execution path (6, b, a) 
which transforms the initial state (0,0) = (x,y) into state (1,2) and correspond 
to the partially ordered moves (1) depicted in figure [H The first move of b is 
greater than the second move of b (presented by an arrow relating the first and 
the second move of b) which is in turn greater than the first move of a. 

Now consider the execution paths {(6, 6, a), (6, a, 6)} which correspond to the 
partially ordered set of moves (2) depicted in figure [T] Intuitively, the second 
move of b and the first move of a can be executed in any order (they are inde- 
pendent) after b has performed its first move. This can be seen in (2) where the 
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(0,0) =(x,y) 




(1.2) 



( 1 ) 

( 2 ) 

( 3 ) 




Fig. 1. Maximal Transition Graph 



second move of b and the first move of a are incomparable. Note that (1) is a 
linearization of (2). 

In figure |T] one can see that the first move of b and the first move of a may be 
independent, too. Consider the execution paths {(a, 6, 6), (6, &, a), (&, a, 5)} and 
the corresponding partially ordered set of moves (3) which additionally expresses 
this independence. 



3.2 Construction 

We present the construction of the maximal transition graph of ASM A as 
a sequential non-deterministic ASM C. We forego a precise definition of the 
underlying vocabulary. In principal, the vocabulary with all its information can 
be extracted from the program. We assume the (single) executing agent to be 
initially in mode ’’initiar . The main program consists of three macros that will 
be explained in the following. 

Following the definition of partially ordered runs moves of a single agent 
are linearly ordered. If, for example, A possesses an agent a then it is natu- 
ral to name the i-th action of a by Ui. An action-name is an element from 
the set ActionName = Agent{A) x Nat. The transition graph TG will be mod- 
eled and constructed as a tuple TG = {tg, — >•) where tg C POAState where 
POAState C State{A) x POA, POA is a partial ordering on action names, and 
— >■ C POAState x ActionName x POAState. 

Main = 

Initial 

Fork 

Join 

In mode 'initiaV ASM C chooses an initial state, initializes the transition graph 
TG = {tg, <) and switches to mode ’fork’. 
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Initial = 

if mode = initial then 

TG := ({(s,0)},0) 

mode := fork 

In mode ’fork’ ASM C expands all maximal POA-states of TG in one step. 
Given a transition graph TG and an agent A, function nextActionName returns 
for a transition graph TG and agent a the next action name of a w.r.t. TG. 
If, for example, TG contains for a only the action names oq, oi, . . . , function 
nextActionName would return Oi+i. Note that in general the bounded explo- 
ration postulate (c.f. i) is violated. This means ASM C does not describe a 
sequential algorithm but a ’definition’ for the notion of transition graph in form 
of a sequential construction process. Note also that in this paper we allow simul- 
taneous extensions of sets (see the TG-assignment). Let A be a partial ordering 
and y ^ X. Then X; {y} denotes the partial ordering in which each element of 
X precedes y. 

Fork = 

if mode = fork then 
forall X S max{TG) do 

TG := TG U {x (state{a), seg{a)) : a € Agent{A)} 
mode := join 
where 

a{a) = nextActionName{TG,a) 
state(a) = N extState A{state{x) , a) 
seg{a) = seg{x) ; {ofc} 

Let X, y be POA-states of TG. We call x and y joinable in TG if cc, y are maximal 
in TG, the states are isomorphic, and the elements of the segments coincide. The 
segments can be joined by means of intersection. Let z be the result of joining 
X and y, i.e. seg{z) = seg{x) 0 seg{y). We call transition graph TG complete if 
TG does not contain joinable elements. 

In mode ’join’ ASM C chooses two joinable elements x,y and join these 
elements. Joining is realized as the deletion of y and the change of seg{x). This 
will be done as long as there are joinable elements. If there are no joinable 
elements, i.e. TG is complete, the mode is set to ’fork’. 

Join = 

if mode = join then 

choose x,y € max(TG) : x ^ y A state{x) = state{y)A 
elements {s eg (x)) = elements {s eg (y)) 

TG:=TG\{y} 
seg{x) := seg{x) n seg{y) 
if complete{TG) then mode := fork 



Let p = {Sk ■ k G Nat) be a run of C and k G Nat such that C is in Sk in 
mode ’fork’. By induction over Nat one can prove that the transition graph of 
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Sk denoted by TGk has the following property: The segment of each element x € 
TGk induces a finite partially ordered run of A. This run is maximal independent 
among all finite partially ordered runs starting from the same initial state that 
possesses the same final state, and for all agents the same number of action 
occurrences. 

Example 2. Consider example |T] and the transition graph (which comes with 
wrong labels and without segments) depicted in Fig. [T] After joining the POA- 
states containing state (1, 1) the joined state possesses the segment ({oq, bo}, 0). 
After joining the POA-states containing state (1, 2) the joined state possesses 
the segment ({oq, &o, ^i}; {^o 6i}), i.e. uq is independent from both bo and bi 

(cf. segment (3) of Fig. [I]) . 

3.3 Applications 

Maximal Independent Rnns. A segment of a POA-state within the maximal 
transition graph induces a finite, maximal independent, partially ordered run. 
This property can be used to analyze and construct maximal independent runs. 



Pre-/Post-states. The maximal transition graph can also be used to determine 
the set of pre- and post-states associated with a move t. In the example H] above 
the set of pre- and post-states of the second move of b w.r.t. the partial ordered 
set of moves (3) depicted in figure [U can be easily found within the maximal 
transition graph: pre-states of this move are related to the transitions (0, 1) to 
(0, 2) and (1, 1) to (1, 2). The pre-states are {(0, 1), (1, 1)} whereas the post-states 
are {(0,2), (1,2)}. 



Indisputable Locations. Whenever a location has the same content in all pre- 
states of a move we say that this location is indisputable for this move (cf. [5]). 
In the example [U the location x (more precisely (a;,())) is indisputable for all 
moves of a in in all partially ordered set of moves (1), (2), and (3). On the other 
side, the location y is indisputable for all moves of b in in all partially ordered set 
of moves. This can be seen directly within the programs associated with a and b. 
For example, the location x is completely under control of a and its content in a 
state completely determined by the a-predecessors within each partially ordered 
set of moves (1), (2), and (3). 

Example 3 (Example [7] continued) . We change the example [T] slightly in the 
following way: 

a: {Enable: } x := x + 1 

b: {Enable: even(x)} y := y + 1 

The program of agent b has changed. It now makes use of the predicate even 
which characterizes the even natural numbers. Moves of agent b are enabled only 
if the content of location x in all pre-states denotes an even number. It is quite 
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obvious how to extend the construction process for transition graphs in order to 
handle such enabling conditions. 

In this example the location y is still completely under control of b. But now 
the contents is also dependent of a-moves. This changes the indisputable portions 
of states which can be directly seen in the corresponding maximal transition 
graph. 

4 Conclusions 

In this paper we have shown how to construct maximal transition graphs and 
how to use maximal transition graphs within verification. The construction itself 
is given as a sequential non-deterministic ASM and consists basically of a fork 
operation and a join operation. The applications of maximal transition graphs to 
the analysis of maximal independent runs, pre- and post-states, and indisputable 
locations shows the usability of maximal transition graphs within verification. 
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Abstract. This paper shows how to use the transformation of Paterson 
and Hewitt to improve the memory and operations used in a pointer 
algorithm. That transformation scheme normally is only of theoretical 
interest because of the inefficient performance of the transformed 
function. However we present a method how it can be used to decrease 
the amount of selective updates in memory while preserving the original 
runtime performance. This leads to a general transformation framework 
for the derivation of a class of pointer algorithms. 

Keywords: Paterson/Hewitt, program transformation, pointer algo- 

rithms, destructive updates 



1 Introduction 

Algorithms on pointer structures are often used in lower levels of implementa- 
tion. Although in modern programming languages (e.g. in Java) they are hidden 
from the programmer, they play a significant role at the implementation level 
due to their performance. But this advantage is bought at high expense. Pointer 
algorithms are very error-prone and so there is a strong demand for a formal 
treatment and development process for pointer algorithms. There are some ap- 
proaches to achieve this goal. 

Several methods rnmn use the wp-calculus to show the correctness of 
pointer algorithms. There only properties of the algorithms are proved but the al- 
gorithms are not derived from a specification. So the developer has to provide an 
implementation. In these approaches proving trivialities may last several pages. 
Butler [3 investigates how to generate imperative procedures from applicative 
functions on abstract trees. To achieve this he enriches the trees by paths to 
eliminate recursion. A recent paper by Bornat shows that it is possible, but 
difficult to reason in Hoare logic about programs that modify data structures 
defined by pointers. Reynolds [T7! also uses Hoare logic and tries to improve a 
method described in a former paper of Burstall |6] to show the correctness of 
imperative programs that alter linked data structures. 

In jl3| Moller proposed a framework based on relation algebra to derive 
pointer algorithms from a functional specification. He shows that the rules pre- 
sented also are capable of handling more difficult multi-linked data structures 
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like doubly-linked lists or trees. However the derived algorithms are still recur- 
sive. Our goal is to improve this method by showing how to derive imperative 
algorithms and so achieve a more complete calculus for transformational deriva- 
tion of pointer algorithms. Based on the method by Moller a recent paper by 
Richard Bird [3j shows how one can derive the Schorr- Waite marking algorithm 
in a totally functional way. 

This paper shows how to use the transformation of Paterson and Hewitt (P & 
H) to derive imperative pointer algorithms. To achieve this we take the recursive 
pointer algorithms derived from functional descriptions using the method of 
Moller. These are transformed via the P & H transformation scheme into an 
imperative version. Despite the inefficient general runtime performance of the 
scheme that results from P & H, we get well performing algorithms. As a side 
effect the amount of selective updates in memory is improved by eliminating 
ineffective updates that are only used to pass through the pointer structure. 
This is not a trivial task, because in general it is not decidable if an update 
really changes links of the pointer structure. Some systems do such optimization 
during runtime but not in such an early state of software development. 

We will show how these aims can be achieved for a class of pointer algorithms 
that first pass through a pointer structure to find the position where they have 
to do some proper changes. A similar transformation scheme for a class of algo- 
rithms that not only alter but also delete links is in preparation. Be aware that 
we are not interested in algorithms that do not alter the link structure but only 
the contents of the nodes (like for example map) . The advantage of the presented 
method over the previously mentioned approaches using wp-calculus or Hoare 
logic are apparent. All these methods provide correct algorithms. However the 
presented one treats a whole class of functions whereas the other methods have 
to be applied on every new algorithm. You also do not have to provide an im- 
plementation for a specification which is a time-consuming task. Not least, the 
transformational approach is more likely to be the easier one to automate. 

The paper is structured as follows: Section [2] defines pointer structures and 
describes some rules needed for the derivation of pointer algorithms from a func- 
tional version. Section O presents as a running example the function cat that 
appends a list to another and explains the problem. Section |4] gives a short 
overview of the methods to get a tail-recursive version from a linear-recursive 
algorithm. The transformation scheme of Paterson and Hewitt is introduced in 
Section El Section El describes the evolution of a transformation scheme to de- 
rive a non recursive imperative pointer algorithm from a recursive one like the 
one presented in Section O Some applications of the scheme to lists and trees 
are shown in Section [3 Finally Section |S] concludes the presented methodology. 
Appendix [Al includes the theoretical basics and the proofs. 

2 Pointer Structures and Operations 

To make this abstract self-contained as far as possible we present a short intro- 
duction to pointer structures and how they are used in |13j . 

In our model a pointer structure V = (s, P) consists of a store P and a list 
of entries s. The entries of a pointer structure are addresses from a set A that 
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form starting points of the modeled data structures. We assume a distinguished 
element o G A representing a terminal node (e.g. null in C or nil in Pascal). 
A store is a family of relations (more precisely partial maps) either between 
addresses or from addresses to node values in a set Afj such as Integer or Boolean. 
Each relation represents a selector on the records like e.g. head and tail for lists 
with functionality A — >■ Afj and A^ A, respectively. 

Each abstract object implemented is represented by a pointer structure (n, P) 
with a single entry n G A which represents the entry point of the data structure 
such as for example the root node in a tree. For convenience we introduce the 
access functions 

ptr{n,L) = n and sto{n,L)=L 

We want to give only the necessary definitions of operations used in this paper. 
More of them and proofs can be found in m- The following operations on 
relations all are canonically lifted to families of relations. Algorithms on pointer 
structures stand out for altering links between elements. Such modification has 
to be modeled in the calculus as well. We use an update operator | (pronounced 
’’onto”) that overwrites relation S by relation R: 

Definition 1. R \ S '^= R LI dom{R) to S 

Here we have used the domain restriction operator ixi which is defined as L ixi 
S = Sn{LxN) to select aparticular part of S' C P(MxN). The update operator 
takes all links defined in R and adds the ones from S that no link starts from in 
R. To be able to change exactly one pointer in one explicit selector we define a 
sort of a “mini-store” that is a family of partial maps defined by: 

„ „ , fc ^ def ( \{x,y)} for selector k\ 

Definition 2. (x ^ y) = < P ^ ^ ^ 

^ \0 otherwise J 

It is clear that overwriting a pointer structure with links already defined in it 
does not change the structure: 

Lemma 1. SCT => S|T = T (Annihilation) 

To have a more intuitive notation leaned on traditional programming lan- 
guages, we introduce the following selective update notation: 

Definition 3. For selector k of type A ^ A 
(n, P).k := (m, Q) (n, {n A m) \ Q) 

which overwrites Q with a single link from n to m at selector k. Selection is done 
the same way: 

Definition 4. 

For selector k of type A ^ A : {n,P).k = {Pk{n),P) 

For selector k of type A^ Nj : (n, P).k T’fc(n) 

To have the possibility to insert new (unused) addresses into the data struc- 
ture we define the newrec operator. Let k range over all selectors used in the 
modeled data structure. Then the operator newrec(L, fc : Xk) alters the store L 
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to have a new record previously not in L and each selector k pointing to Xk- So 
for example newrec(L , head : tail : o) returns a pointer structure {m,K) with 

m a new address previously not used in L and store K consisting of L united 
with two new links (m 3) and (m o) . If it is clear from the context which 
selectors are used we only enumerate the respective components. So the previous 
expression becomes newrec(L, (3,o)). 

3 A Running Example and the Problem 

In this section we want to use a functional description of list concatenation. This 
function serves as our running example during the derivation of the transforma- 
tion scheme. We will use Haskell notation to denote functional algorithms: 

cat [] ys = ys 

cat (x:xs) ys = x : cat xs ys 

We assume that the two lists are acyclic and do not share any parts. So the 
following pointer algorithm can be derived by transformation using the method 
of [I3]: 

catp{m, n, L) = \f m ^ o then (m, L).tail := catp^Ltaiiim) , n, L) 

else (n, L) 

The two pointer structures (m, L) and (n, L) are representations of the two 
lists. Addresses m and n model the starting points, whereas L is the memory 
going with them. In other words m and n form links to the beginnings of two 
lists in memory L. 

Note that this is only one candidate of possible implementations for the func- 
tionally described specification of cat. Because we are interested in algorithms 
performing minimal destructive updates we did not derive a persistent variant 
such as the standard, partially copying interpretation in functional languages. 
But that would also be possible. 

We now have a linear recursive function working on pointer structures. But 
what we want is an imperative program that does not use recursion. By investi- 
gating the execution order of catp we can see, that catp calculates a term of the 
following form: 



{m,L).tail := {{Ltau{m) , L) .tail := ...{n,L)) 

If you remember the definition of the := operator, this means that updates are 
performed from right to left. 

(m L,^u{m)) I (. . . I {{LlM n) \ L) . . .) 

This shows that the derived algorithm uses the update operator not only to 
properly alter links but also to just pass through the structure while returning 
from the recursion. Figure [T] shows how these updates are done in the example 
of cat (=> denotes the actually altered links). 
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I — — I tail I 1 tail i 1 

mo ^ mi — m2 



O n 



tail 

. rrii-i I > 1 nij | | m | ■ 



tail I 1 tail 



tail I 1 tail 



tail I 1 tail 



tail I 1 tail 




Fig. 1 . Order of updates performed by cat 



As we can see, there are several such updates that do not alter the pointer 
structure. For example (m Ltaaim)) is already contained in L and does not 

change the pointer structure (. . . | n) \ L) . . .) if the previous 

updates do not affect this part of L. This is the case for several algorithms 
on pointer linked data structures, because most of them first have to scan the 
structure to find the position where they have to do the proper changes. 

We now define the following abbreviations to get a standardized form for 
later transformations: 

K{m,n,L) L) B{m,n,L) m yf o (f)k{u,v) v.k := u 

H{m,n, L) (n,L) E{m,n, L) {m,L) 

Abbreviating (m, n, L) to x the derived pointer algorithm can then be written 
as 



catp{x) = \f B{x) then (j)taii{catp{K{x)),E{x)) 
e\seH{x) 



4 From Linear via Tail Recursion to While Programs 

In transformational program design the transformation of a linearly recursive 
function to an imperative version always has two steps: First transform the 
linear recursion into tail recursion. Then apply a transformation scheme [1 .b| like 
the following to get a while program: 
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fix) 



fix) 



\f B{x) then f{K{x)) 
e\seH{x) 



varwx := x] 

while do := K{vx); 
H{vx); 



But catp does not have tail recursive form. So we first have to find a way to 
transform catp into the right form. There are several schemes to derive a tail 
recursive variant from a linear recursive function [J. One of the most popular 
is to change the evaluation order of parentheses in the calculated expression. To 
be able to do this one needs a function ip that fulfills the equation s),t) = 

'ip{s, t)). To find such a "0 is possible only in very rare cases of </>. One of these 
is that 4> is associative. In this case you can choose ijj = (j). Another - similar - 
case is to change the order of operands. Here it is necessary that cj){(j){r,s),t) = 
4>i4>ir, t), s) or more generally you need a V' with s),t) = ip{4>{r, t),s). The 

previously described rules assume that </) is good-natured enough to satisfy one 
of the properties mentioned. However, our function 4>taiiiu,v) in catp does not 
show any of these properties. Another transformation uses function inversion to 
calculate the parameter values from the results. Here one only has to find an 

inverse K of K. But the function K{m,n, L) = {Ltauim),n,L) in general is 
not invertible. So is there no way to get a tail recursive version of catp ? 



5 The Transformation Scheme of Paterson/Hewitt 

In 1970 Paterson and Hewitt presented a transformation scheme that makes it 
possible to transform any linear recursive function into a tail recursive one m- 
This rule normally is only of theoretical interest because of the bad runtime 
performance of the resulting function. P & H applied the idea of the method 
mentioned in Section fusing the inverse function K to make the step from 
to K^, but exhaustively recalculated iP® from the start. The evolving scheme is: 



F{x) = \fB{x) then(j){F{K{x)),E{x)) 
e\seH{x) 

1 [ P & H 

F(x) = G(n0, i7(m0)) where 
(toO, nO) = num{x, 0) 
num(y, i) = if B(y) then num{K{y),i + 1) 
else(?/,i) 

it{y, z) = if z yf 0 then it{K{y),i — 1) 
elsey 

G(z, z) = if z yf 0 then G(z — 1, (j){z, E{it{x, i — 1)))) 
else z 



The function num calculates the number of iterations that have to be done until 
the termination condition is fulfilled, as well as the final value. These values are 
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used by function G to change the evaluation order of the calculated term. For 
this, G uses the function it to iterate K to achieve the inverse iF of iF by doing 
one iteration less than has to be done for K. So G can start with the calculations 
done in the deepest recursion step first and then ascend from there using the 
inverse of K. 

As we have seen, function it is only used to calculate the powers of K 
and we have it{y,i) = K^{y), so we can abbreviate 4>{z, E{it{x,i — 1))) to 
4>{z, and simplify the scheme: 

E{x) = \tB{x) then (f>k{E{K{x)), E{x)) 
else iJ(x) 

'I [ Paterson/Hewitt II 

E{x) = G{nO, H{mO)) where 
(mO,nO) = num{x,0) 
num{y, i) = if B{y) then num{K{y),i + I) 
else(y,z) 

G{i, z) = if z yf 0 then G(z — I, (j>k{z, E{K'‘~^{x)))) 
else z 

This certainly is only a cosmetic change, because K'‘~^ has to be calculated 
exactly the same way as in the original transformation scheme. But this gives 
the basis to future simplification, because K^~^{x) is only used as a parameter 
for E and will be eliminated in further steps. 

6 Deriving a General Transformation Scheme 

We now present an application of the P & H transformation scheme to pointer 
algorithms using the function (j)^ to pass through a pointer data structure. The 
whole derivation from a more theoretical point of view including all calculations 
and proofs can be found in the appendix. 

k 

By investigation of function (f>k{{m,L),{n,L)) = (rz, (rz — >■ m) | L) we can 
see that <pk updates the link starting from m via selector k and simultaneously 
sets rz as the new starting entry of the resulting pointer structure. It is apparent 
that such a restricted function can not provide the simplification we aim to 
achieve, namely elimination of effect-less updates. So we use the technique of 

k 

generalization and introduce a more flexible function (n, L)) = {I, {m — >■ 

rz) I L) that handles the altered address and the resulting entry independently. 
With this function we are in the position to eliminate the quasi-updates that 
do not alter the structure but are only used for passing through the pointer 
structure. One can say that tpk “eats up” the effect-less updates of (j)k- 

Lemma 2. If {t \ v) Q {v \ u) \U then for all s 

t, (j)k{{u, U), {v, U))) = ifk{s, V, (rz, U)) 

Now we return to the P & H transformation scheme. There the function G applies 
4>k so that this lemma can be used to simplify G. We apply the lemma to all 
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instances of G that only pass through the pointer structure. This means as long 
as the condition B is fulfilled we apply Lemma El and eliminate one application 
of (pk- So the precondition of Lemma |2] has to hold for all those cases. 

Lemma 3. We abbreviate ptr{E{K'‘{x))). Then under the condition 

Vi G {0, ... , nO} : ptr{z) = V A (p^*“^\p^*^) G sto{z)) 

we can simplify G{i, z) to: 

G(i, z) = if i yf 0 then tpk{ptr{E{x)) ,ptr{E{K"^~^ {x))) , z) 
else z 

Remembering that K is the function performing the run through the pointer 
structure we can express the condition in human-understandable form. The pair 
(p(*-i)^p(d) consists of the values under function E of two such successive ele- 
ments that are met during the pass-through via K . Now, either these are equal 
which means the links form a cycle and the simplification is trivial. Or they are 
not equal and the memory already contains the link. Then an update using these 
values will not change anything and can be eliminated. 

With nO = min{j : {x))} this is a condition that in some cases can 

not be checked easily. But normally one proves a more general assertion. For 
function cat for example we have acylic lists and we can show that the condition 
holds for all successive pairs of elements in the list. 

Now that G is not recursive anymore we can instantiate the application of G 
with its actual parameters. The test i y^ 0 is only calculated once. By inspection 
of num that calculates nO (the actual argument for parameter i) we see that the 
inequality test can be done without nO: 

Lemma 4. nO yf 0 B{x) 

So the scheme of Paterson and Hewitt simplifies to 

E{x) = B{x) thev\ipk{pi'r{E{x)),ptr{E{K'^^~^{x))),El{mQi)) 
else 7L(mO) 

where (mO, nO) = num(a;, 0) 

num{y, i) = if B{y) then num{K(y),i + 1) 
else {y,i) 

A straightforward induction shows that mO = K^^{x). So the calculation of mO 
can be done simultaneously with the calculation of This is achieved by a 

slightly changed pair of functions num' and num" that replace num. For this we 
extend the domain of iV by a special element with K{Ax) = x that models 
an imaginary predecessor of x under K: 

num' {y) = ifR(p) then num" {y) 
else Ay 

num"{y) = \f B{K{y)) then num" {K (y)) 
else y 



and obtain 



124 



T. Ehm 



Lemma 5. num!{x) = ^(a;) and thus also mO = K(num'{x)) 

This is the basis for the following transformation: 



F{x) = \f B{x) thentpi.{ptr{E{x)),ptr{E{kO)),H{K{kO))) 
e\se H{K{kO)) 
where fcO = num'{x) 

num'{y) = B{y) then num''{y) 
else Ay 

num"{y) = B{K{y)) then num" {K{y)) 

else y 

'I [ unfold num' and kO 

E{x) = B{x) thenij:k{ptr{E{x)),ptr{E{kQ)),H{K{kQ))) 
else if(_ftT(if B{x) then num"{x) else A^;)) 
where ktt — \^B{x) then num"(a:) 
else Aj; 

num"{y) = B{K{y)) then num" {K{y)) 

else 2/ 



Although there is a term E{kO) in the scheme the case that E{Ax) has to be 
evaluated can never be reached. So there is no need to define E{Ax). Now num" 
is the only recursive function; it is even tail-recursive so that we are in the 
position to use the transformation scheme presented in Section [4| to achieve an 
imperative while program: 



E{x) 



E{x) 



\f B{x) then ijjk{ptr{E{x)),ptr{E{kO)),H{K{kO))) 
e\seH{x) 

where kO = if B{x) then varvx:=x 

while B{K{vx)) do vx := K{yx) 
vx 
else Aj. 

'I [ Simplification 

varna; := x 

if B{x) then whWe B{K{vx)) do vx := K{vx) 

ipk{ptr{E{x)),ptr{E{vx)),H{K{vx))) 

e\seH{x) 



The scheme that has evolved from our calculations now is: 



F{x) 



F{x) 



if B{x) then <j){F{K{x)), E{x)) 
e\seH{x) 

'I [ Conditions of Lemma El 

varwa; := x 

if B{x) then whWe B{K{vx)) do vx := K{vx) 

ijjk {ptr{E{x) ) , ptr{E{vx)), H{K{vx))) 
else H{x) 
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To return to our example in the previous sections we now can transform 
the recursive version of catp to an iterative program by using the derived 
scheme. First we check the applicability condition of our scheme abbreviating 

= LIM-. 



Vf e {0, . . . ,min{j : Tj = o}} : n = T* = Ti_i V {Tt ^ Ti^i A (Ti_i,Ti) G L) 

The first disjunct is not fulfilled by the assumption that the two lists do not 
share any parts. But the second disjunct is true by acyclicity of p. So some 
simplification leads us to the imperative algorithm one has in mind: 



catp{m,n, L) = var {vm,vn,vL) := {m,n,L) 



catp{m, n, L) = var vm := m 



ifmy^o then while Ltaii{vm) ^ o Ao 

{vm,vn,vL) := {vLtaii{vm),vn,vL) 
{vn,vL)) 

else {n,L) 

-j; [ vn, vL constant 



if m o then wWde Ltaii{vm) <> do vm := Ltaii{vm) 

(to, {vm n) I L) 
else {n,L) 



This formally derived program can directly be translated into a C program by 
mapping the pointer algebra operations into their corresponding C equivalents. 
Note that the memory L remains implicit: 

list catClist m,list n) { 
list vm = m; 

if (m) ■[ while (vm->tail) vm=vm->tail; 
vm->tail=n; 
return m; 

> 

else return n; 

} 



7 Further Applications 

In this section we want to show that the developed scheme is applicable to several 
algorithms passing through a pointer-linked data structure. 



7.1 Insertion into a Sorted List 

In [5] several algorithms on lists are derived with the calculus presented in jlS]. 
We choose insertion into a sorted list as a first example. The function insert is 
defined like this: 
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insert x [] = [x] 

insert x (y;ys) = if x < y then x:(y:ys) 

else y: (insert x ys) 

We can bring the derived pointer algorithm insertp into the form needed by our 
scheme. 

insertp{m,n, L) = 

if n yf o A Lyai{rn) > Lhead{n) then q.tail := insertp{m, Ltaii{n),L) 

else newrec(L, {Lyaiim), (n, L))) 

Now we can apply the scheme and after a simplification step achieve an 
imperative algorithm for insertion into a sorted list: 

insertp{m,n, L) = 
var vn := n 

if (n yf o A Lyai{m) > Lhead{n)) then 

while {Ltaii{vn) yf oAL„a/(m) > Lhead{vn)) do vn := Ltaii{vn) 
iptaiiin, vn, newrec(L, (Lyai{m), {vn, L)))) 
else newrec(L, {Lyai{m), {n, L))) 



7.2 Insertion into a Tree 

To show an example using a data structure different from lists we show how 
insertion into a tree can be derived from our scheme. It is nearly as easy as 
the other examples. We use the algorithm derived in m from the following 
functional specification: 

ins x Empty = Tree(Empty,x, Empty) 

ins x Treed, y,r) = if x < y then Tree(ins x l,y,r) 

else Treed, y, ins x r) 

The selectors used to model trees are val for node values as well as I and r for 
the left and right descendant. We abbreviate u.val = Lyai{u) and p = {ni,L) as 
before and get: 

insp X p = if TO = o then newrec(L, (o,x,o)) 

else if X < m.val thenp.^ := inSp x p.l 
elsep.r := inSp x p.r 

The algorithm can be transformed into the form needed by our scheme with 
the help of the conditional operator _ ? _ : _ as used in several programming 
languages. 

inSp X p = if TO yf o then <l>(x<m.vai?i-.r){'i'nsp x (x < m.vallp.l : p.r)),p) 
else newrec(L, (o, x,o))) 

Now we can use our scheme to achieve an imperative algorithm for insertion into 
a tree. 
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inSp X (to, L) = 
vartiTO := to 

if TO ^ o then while {h := x < vm.vall Li{vm) : Lj.(ym)) ^ odowTO := h 
V’(x< vm.v ain-.r) (to, WTO, newrec(L, {o,x,o)) 
else newrec(L, (o, x, o)) 

Here we have used an assignment inside the condition of the while loop. Other- 
wise the algorithm would have to use the conditional operator _ ? _ : _ twice 
or introduce two new while loops. But we do not think this would make the 
algorithm more readable. 

8 Conclusion 

We have shown how the transformation of Paterson and Hewitt can be used 
to construct imperative algorithms on pointer-linked data structures. Although 
the transformation of Paterson and Hewitt normally is only of theoretical in- 
terest because of its very bad runtime behaviour, well-performing algorithms 
are derived. This leads to a general methodology for the derivation of pointer 
algorithms. 

By the example algorithm for insertion into a tree it can be seen, that there 
is a need for more sophisticated schemes based on the presented one. It also is 
likely that algorithms changing more than one link such as deletion from a list 
can be treated the same way. For this, one has to divide the job into several 
parts altering only one link, applying the scheme and afterwards putting the 
parts together. 

Further research will investigate this and other starting points to complete 
the methodology. Also a (semi-) automatic system checking the side-conditions 
and so supporting the developer of such algorithms is under development. 
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A Proofs 

Here we show the proofs and calculations skipped in Section E] 

Proof of Lemma 

(j)k{{u,U),{v,U))) 

= ipk{s,t,{v,{v A u) I [/)) 

= (s,(tAz;)|((z;4u)|C/)) 

= |C7) 

= ipk{s,v,{u,U)) 

k k 

The equality labeled with ann holds by annihilation if (t — ?> u) C (u — >• u) | U. 
So the following conditions arise (We can restrict the calculation to k, the only 
selector used here): 

(i 4 u) C (u -T u) \U 
{{t, t;)} C {(■(;, u)} U dom{{{v, u)}) to U 
(t,v) € {(w,u)} V (t,v) S {t>} to U 
{t = V A V = u) V {t V A {t,v) G U) 

^ [t = u = v) \/ {t ^ V A (t,v) G U) (*) 
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Proof of Lemma [31 We use Lemma (21 and induction over i: 

i = 0: G(0, z) = z 
i 1 z + 1: 

G{i + l,z) 

= {[ definition of G and z + 1 0 ]} 

= {[ induction hypothesis ]} 

ifz 0 ther\'il)k{ptr{E{x)),ptr{E{K^-^{x))),(l3k{z,E{K^{x)))) 
else z 

= {[0 and lemma [2]]} 

if z 0 then tjjk{ptr{E{x)) , ptr{E{K^ (x))) , z) 
else z 

Proof of Lemma |3) 

rzO yf 0 

{[ definition of rzO ]} 
snd{num{x, 0)) yf 0 

{[ definition of num ]} 
snd{\f B{x) then num{x, 1) else {x, 0)) yf 0 
{[ propagation of snd and yf 0 ]} 

(B{x) A snd{num{x, 1)) yf 0) V {~^B{x) A false) 

{[ snd{num{x, z)) = 0 O z = 0 ]} 

B{x) 

Proof of Lemma [^ First let h{x,y,i) = So we can derive 

a recursive definition of h by: 

h{x,y,i) 

= {[ definition of /z ]} 

j^snd{num{y,i)) — l 

= {[ definition of num ]} 

j^snd{\^ B{y) then num(K [y) ,z+l) else (y,i)) — 

= {[ propagation of K, snd and — 1 ]} 

\fB{y) then 
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= {[ definition of ]} 

ifS(y) then /i(x, iir(y), i + 1) 
else 

By computational induction we now show 

num"{K’'{x)) = h{x, K^~^^{x),i + 1) (*) 

num" {K'‘ {x)) 

= {[ definition of num" ]} 

B{K{K'‘{x))) then num" {K{K^{x))) 
else K^{x) 

= {[ induction hypothesis ]} 

if then h{x, K{K^~^^{x)), (i + 1) + 1) 

elseit'(*+^^“^(x) 

= {[ recursive definition of h ]} 

h{x, K^~^^{x),i + 1) 

Using the special case h{x,K{x), 1) = num"{x) of this equivalence, we can show 
the claim: 

= {[ definition of nO ]} 

j^snd{num{x,Qi)) — l 

= {[ definition of /i ]} 

h{x, X, 0) 

= {[ recursive definition of h ]} 

\f B{x) ther\h{x,K{x),l) 

else Ax 

= H by Q ]} 

ifB(x) then num" (x) 
else Ax 

= {[ definition of num' ]} 

num' (x) 
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Abstract. Equivalent transformation (ET) is useful for synthesis and 
transformation of programs. However, it is not so clear what seman- 
tics should be preserved in synthesis and transformation of programs in 
logic and functional programming, which come from the disagreement 
of computation models (inference or evaluation) and equivalent transfor- 
mation. To overcome the difficulty, we adopt a new computation model, 
called equivalent transformation model, where equivalent transformation 
is used not only for program synthesis, but also for computation. We 
develop a simple and general foundation for computation and program 
synthesis, and prove the correctness of ET-based program synthesis. 

1 Introduction 

Equivalent transformation is one of the most important methods for program 
synthesis and transformation [^. For instance, in logic programming [^, a predi- 
cate definition consisting of first order formulas or definite clauses is transformed 
equivalently into a (more efficient) logic program (i.e., a set of definite clauses) 
by using unfolding, folding, goal replacement, and other transformations. In 
functional programming, a function definition is transformed equivalently into 
a (more efficient) functional program by using unfolding, folding, tupling, and 
other transformations. 

In this paper we develop a theoretical foundation of program synthesis by 
equivalent transformation (ET), define basic concepts, and prove correctness of 
ET-based program synthesis. This theory should contain the following items: 

1. Definition of specification, computation, and programs, 

2. Definition of correctness of computation and programs (with respect to a 
specification), 

3. Relation between computation and equivalent transformation, 

4. Proof of correctness of programs obtained by equivalent transformation. 

It should be noted that such a theory has not been fully established in the 
existing theories of logic or functional programming. For instance, computation 
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is regarded not as equivalent transformation but as logical inference (resolution) 
in logic programming and it is not clear which declarative semantics should be 
preserved in equivalent transformation for correct program synthesis. 

Instead of developing a theory in the existing frameworks of logic or func- 
tional computation model, we adopt a new computation model, called equiva- 
lent transformation model [T]. In the equivalent transformation model, equiv- 
alent transformation is used not only for program synthesis but also for compu- 
tation. This enables us to make a simple and general foundation for computation 
and program synthesis. 

Our theory consists mainly of the following sections: 

1. Theory of Computation, 

2. Separated Descriptions, 

3. Program Synthesis by Equivalent Transformation. 

Outline of the theory is summarized as follows. 

1. Theory of Computation 

General computation theory is developed on base structures called represen- 
tation systems, where each description is associated with its meaning. A 
rewriting rule is used to transform a description into another description. 
A rewriting rule is called an equivalent transformation rule (ET rule for 
short) iff it preserves meanings of descriptions. Computation is defined as 
transformation of descriptions. Computation is correct iff it is equivalent 
transformation of descriptions. A program is a set of rewriting rules. A 
program is correct iff it consists of only ET rules. A correct program 
produces correct computation. 

2. Separated Descriptions 

We introduce a subclass of representation systems, called separated rep- 
resentation systems, where (1) a description consists of two parts, a d- 
description and a q-description and (2) meaning of a description (d,q) 
depends only the q-description q and meaning of the d-description d. Such 
description is called a separated description. A description in logic program- 
ming is regarded as a separated description consisting of a predicate definition 
(= d-description) and a query (= q-description). 

We also assume that only q-descriptions are changed by rewriting rules 
and the d-descriptions are left unchanged in computation. 

3. Program Synthesis by Equivalent Transformation 

A specification is determined by a pair of a d-description and a set of q- 
descriptions. A rewriting-rule-set generator is a mapping that associates 
each d-description with a set of rewriting rules. An ET-rule-set generator 
is a rewriting-rule-set generator that gives, for each d-description, a set of 
ET rules. 

A correct program (= a set of ET rules) with respect to a specification 
consisting of a d-description d is obtained in the following two phases: 
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1 . equivalent transformation of the given d-description d into another d- 
description d' , and 

2. the new d-description d' is mapped by an ET-rule-set generator into a 
program (= a set of ET rules). 

2 Theory of Computation 

2.1 Representation System 

A representation system is a triple {Des, v, Meg) of two sets, Des and Meg, 
and a mapping v from Des to Meg. Each element of Des and Meg are called a 
description and a meaning, respectively. A relation ~ on Des is defined by 
desi ^ des 2 v{desi) = v{des 2 ). 

Obviously ~ is an equivalence relation. 

Example 1. Let V{A) be the powerset of the set of all definite clauses on an 
alphabet A. Let Q be the set of all ground atoms on the alphabet A. Let Des\ 
be 'P{A), Megi the powerset 2®, and vi a mapping M from P{A) to 2® that 
determines so called the “declarative semantics” of P for each P in P{A). Then 
{Desi,vi, Megi) is a representation system. 

2.2 Problem Formalization Based on Meaning 

A problem on a representation system {Des, v, Meg) is a triple 
a = (des, 7T, /C), 

where des is a description in Des, /C is a set, and tt is a mapping from Meg to 
1C. The problem 
a = {des, 7T, K) 

on a representation system {Des, v, Meg) requires to find the element k in JC 
determined by k := TT{v{des)). 

Example 2. Let C\, C 2 , and C 3 be the following definite clauses, where app 
means append. 

Cl initial{X, Z) -<r- app{X, Y, Z). 

C 2 app{[],Y,Y) 

C 3 app{[A\X],Y, [A|Z]) ^ app{X, Y, Z). 

Let Cq be a definite clause 

yes initial {[\, 2], [1, 2, 3, 4]). 

Let 7 Ti be a mapping from 2^ to {yes, no} that is defined by 

7 Ti(G) = yes yes € G, 

= no yes ^ G. 

Then ai = ({Gi, G 2 , G 3 , G^}, tti, {yes, no}) is a problem to judge whether [1,2] 
is a first part of [1, 2, 3, 4]. Since Ad(|Gi, G 2 , G 3 , Cq}) includes the yes atom, the 
answer of Problem a\ is “yes^\ 
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2.3 Transformation by Rewriting Rules 



A rewriting rule on Des is defined as a subset of Des x Des. A description des\ 
is rewritten into a description des 2 by a rewriting rule r, denoted by desi — >■ des 2 , 
iff (desi, des 2 ) S r. Let Rw be a set of rewriting rules. A description des\ is 
rewritten into a description des 2 by i?rc, denoted by des\ ^ des 2 , iff there is a 
rewriting rule r in Rw such that desi — >■ des 2 - 

One way to solve Problem a = (des, tt, /C) on a representation system 
{Des^v,Meg) is shown. 

Algorithm A(Rw) 

Let Rw be a set of rewriting rules on Des. 

Input: a problem a = {des,TT,IC). 

Output: an element in /C. 



1. Assume that a problem a = (des, 7r,/C) on {Des, v, Meg) is given. 

2. Transform des in Des by repeated application of rewriting rules in Rw into 
des' in Des. 



7 7 Rw 7 Rw 7 Rw 

des = desi — >• des 2 — >• des^ — >• 



Rw 



desn = des' 



3. Calculate k := Tr{v{des')) and return k. 



Example 3. For instance, 

rl: initial{b,X,b,Z) — >■ app{SzX,=f)^Y,SzZ). 

is used to replace an initial atom in the body of a clause with an app atom that 
satisfies the following conditions 0 : 

— The first and the third arguments of the app atom are the same as the first 
and the second arguments of the initial atom, respectively. 

— The second argument of the app atom should be a “new” variable that does 
not appear in other part of the clause. 

This is a rewriting rule (i.e., it is a subset of Des\ x Des\, where Des\ is in 
Example [TJ) since it determines the set of all pairs {des, des') of descriptions in 
Desi such that des is rewritten into des' by rl by replacement of an initial 
atom in a clause in des with an app atom. 



Example 4- Let P\ be a set of rewriting rules: 

Pi = {rl,r2,r3}, 

where rl is in Example |3] and other two rules r2 and r3 are given as follows. 

r2: app{[],SzY,kZ) ^ {SzY = kZ}. 

r3: app{[kA\kX],kY, kZ) {kZ = [kA\#W]}, 

app{kX, kY, ifW). 

The process of rewriting the definite clause Cq is as follows. 



1 



See appendix and |2] for explanation of rules. 
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yes ^ initial{[l, 2], [1, 2, 3,4]). 
yes ^ app{[l,2],Y, [1,2, 3,4]). by Rule rl 
yes ^ app{[2],Y, [2,3,4]). by Rule r3 

yes ^ app\ [ ] , F, [3 , 4] ) . by Rule r3 

yes by Rule r2 

Since the last description des' obtained by the above rewriting contains the 
clause yes it follows that 7Ti(z;(des')) = yes and “yes” is obtained as the 

output of Algorithm A({rl, r2, r3}). 

2.4 Problem Solving Based on Equivalent Transformation 

An equivalent transformation (ET) rule is defined as a rewriting rule r that 
satisfies v{desi) = v{des 2 ) for all pairs {desi^des^) in r. In order to transform 
elements in Des equivalently, ET rules are used. 

Theorem 1. If the set Rw consists only of ET rules, the Algorithm A(Rw) gives 
a correct answer for any problem a. 



Example 5. Three rewriting rules (rl, r2, and r3) in Example 2] are ET rules. 
For instance, iT is an ET rule since rl works in the same way as unfolding at an 
initial atom. Since rl, r2, and r3 are ET rules. Problem a\ is correctly solved 
by using Algorithm A({rl, r2, r3}). 

2.5 Program Consisting of ET Rules 

A set P of rewriting rules can be regarded as a program, since P determines 
a (possibly nondeterministic) algorithm based on the Algorithm A(Rw). If a 
program P consists only of ET rules, then computation by P is correct, i.e., a 
correct answer for Problem a is obtained. 

Example 6. Let P 2 be a set of ET rules: 

P 2 = {r4,r5}, 

where r4 and r5 are given as follows. 

r4: initial{[SzA\&6X],&6Z) — >■ {SzZ = [&A|:;(^1T]}, 

initial{k.X, ffW). 

r5: initial{[],hZ) — >■ {true). 

P 2 is a correct program for ai. 



3 Separated Descriptions 

3.1 Separated Representation Systems 

Let C be a definite clause. Let head{C) and body{C) denote, respectively, the 
head atom of C and the set of all atoms in the body of C. Let S be the set of 



136 



K. Akama, H. Koike, and H. Mabuchi 



all substitutions on A. Let i?a and i?f, be sets of predicates. A clause C is from 
Ra to Rb iff all predicates of atoms in body{C) are in Ra and the predicate of 
head{C) is in Rb- 

The description {Ci, C2, C3, C^} in Problem a\ in Example |2] consists of 
two parts, do = {C'i,C2,C'3} and = {Cg}. The meaning of the description 
do U go = {C*!, C2, C3, Cq} satisfies 

M{do U go) = M{do) U f(Ad(do), go), 
where 

t(G, q) = {h\C€q, 0 €S,h = head{C 6 ) G G, body{C 9 ) C G}. 

Hence there is a mapping m such that 
Ad (do U go) = m(Ad(do), go). 

This example motivates us to introduce the following definition. 

A separated representation system is a six-tuple 
{Ds, Qs, w, Ms, m, Meg) 

of two sets Ds and Qs for descriptions, two sets Ms and Meg for meanings, a 
mapping w from Ds to Ms, and a mapping m from Ms x Qs to Meg. 

Assume that {Ds,Qs,w, Ms,m, Meg) is a separated representation system. 
If we define a set Des as Ds x Qs, and a mapping v from Des to Meg by 
v{des) = m{w{d),q) 

for all des = (d, g) in Des, then {Des, v, Meg) is obviously a representation sys- 
tem, which is called the associated representation system of the separated 
representation system {Ds, Qs, w, Ms, m, Meg). 

A separated representation system {Ds,Qs,w, Ms,m, Meg) is always iden- 
tified with its associated representation system. 

Hereafter we assume that we are given a separated representation system 
r = {Ds,Qs,w,Ms,m,Meg). 

Example 1 . Let i?i and Ri be mutually disjoint sets of predicates: 

Ri = {initial, app, equal, rev}, 

R2 = {yes, ans}. 

Let Dsr be the powerset of the set of all definite clauses from i?i to Ri, Qsj 
the powerset of the set of all definite clauses from Ri to R2, Msr the powerset 
of the set of all ground atoms on Ri, and Meg^j the powerset of the set of all 
ground atoms on R\ U i?2- Let wt be a mapping from Dsy to Msy such that 
WT^d) = M{d). 

Let TO7 be a mapping from Msr x to Meg-^ defined by 
mriG, q) = GUt{G,q), 
where t is defined in Section [3. II Then 
LV = {DsT,Qs’j,WT,MsT,m'j,Megj) 

is a separated representation system. Let {DesT,V’j, Meg^j) be the associated 
representation system of the separated representation system TV. Then 
V7{{d,q)) = Ad(dUg) 
for all (d, g) G Des-j. 
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3.2 Rewriting Rules and ET Rules 

A subset r of Qs x Qs and an element d in Ds determines a rewriting rule r': 
r' = {{{d,q),{d,q')) \ {q,q') € r}, 

which is called the associated rewriting rule of r with respect to d. A subset 
r of Qs X Qs is called a rewriting rule on Qs. A rewriting rule r on Qs is called 
an ET rule with respect to an element d in Ds iff the associated rewriting rule 
r' of r with respect to d is an ET rule. Obviously a rewriting rule r on Qs is an 
ET rule with respect to d in Ds iff 
m{w{d),q) = m{w{d),q') 

for all {q,q') € r. A description (d,q) in Ds x Qs is equivalently transformed 
into (d, q') in Ds x Qs by an ET rule r on Qs with respect to d in Ds. 

4 Program Synthesis by Equivalent Transformation 

4.1 Specificatiou 

Let r = {Ds, Qs, w, Ms, m, Meg) be a separated representation system. A spec- 
ificatiou on T is a pair {d, Q) of d in Ds and a subset Q of Qs. A specification 
{d, Q) on r requires a program to answer all problems (d, q) such that q € Q. 



4.2 ET-Rule-Set Generator 

Let r = {Ds, Qs, w, Ms, m, Meg) be a separated representation system. A map- 
ping g from Ds to the powerset of the set of all rewriting rules on Qs is called 
a rewritiug-rule-set generator on D. For all d in Ds, a rewriting-rule-set 
generator g on D determines a set g{d) of rewriting rules on Qs. 

A rewriting-rule-set generator g on E is called an ET-rule-set generator 
on r iff, for all d in Ds, each element in g{d) is an ET rule with respect to d. 

Example 8. do is a set {Ci, C2, C3} in Section im Let go be a rewriting-rule-set 
generator that generates, for each predicate, one rewriting rule that is similar to 
the set of all flatten clauses of the definition clauses for the predicate [E Then, 
5 o( 4) = where 

r6: app(&P, &Q, &i?) — >■ {&P = [], &Q = &i?}; 

^ {kP = [#A\#X],kR = [#A\#Z]}, 
app{#X,#Y,#Z). 



4.3 Obtaining ET-Rules by Equivalent Transformation 

Theorem 2. Assume that g is an ET-rule-set generator on E. If two elements 
d and d' in Ds satisfies w{d) = w{d'), then g{d') is a set of ET rules with respect 
to d. 



2 



See |3| for precise definition and the correctness of rules that are obtained by go. 
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Let r = {Ds,Qs,w, Ms,m,Meg) be a separated representation system. 
Since w is a mapping from Ds to Ms, {Ds,w, Ms) is a representation system. 
A relation ^ on Ds is defined by 
di ^ d,2 w{di) = w{d2). 

Obviously ~ is an equivalence relation. According to the general definitions of 
rewriting rules and ET rules, a rewriting rule r on Ds is an ET rule on Ds iff 
w{d) = w{d') for all {d,d') in r. 

Algorithm B(Rw, g) 

Let Rw be a set of rewriting rules on Ds, and g a rewriting-rule-set generator 
on r. 

Input: a specification {do,Q) on D 
Output: a set of rewriting rules on Qs. 



1. Transform do into by repeated application of rewriting rules in Rw, i.e., 



do 



Rw , Rw 
di ^ 



Rw 



Rewriting rules may be applied any finite times (n > 0) as long as they are 
applicable. 

2. From d„, obtain a set of rewriting rules g{dn) by using the rewriting-rule-set 
generator g. 



Theorem 3 . If all rewriting rules in Rw are ET rules and g is an ET-rule-set 
generator on E, then the set of rewriting rules obtained by Algorithm B(Rw, g) 
is a set of ET rules with respect to do- 

Example 9. Assume that the set do = {C\,C2,Co} in Section [3.11 is trans- 
formed equivalently by using unfolding and folding into a new set c ?2 = 
{On, Ci 2 , O 2 , O 3 }, where 
On initial{[], Z) . 

O12 initial\[A\X], [A|Z]) ^ initial{X , Z) . 

From d 2 we obtain a set 170 (^ 2 ) = {r6,r7} of ET rules using the ET-rule-set 
generator go- 

r7: initial{SzP, EzR) (&P = [], = ffZ}-, 

^ l&P = [#A|#A],&i? = [#A|#Z]}, 
initial{ffX, ffZ). 

The set |r6,r7} is a correct program with respect to do- 



5 Concluding Remarks 

A theoretical basis for program synthesis by equivalent transformation has been 
developed. Given a specification (do,Q) on a separated representation system 
E — {Ds, Qs, w, Ms, m, Meg), a program is obtained by transforming do equiv- 
alently into dn and by mapping using an ET-rule-set generator g. An element 
d in Ds is transformed in program synthesis preserving meaning w{d) of d, 
while an element q in Q is transformed in computatiou preserving meaning 
m{w{d),q) of {d,q). This theory can be applied to many declarative programs 
including logic and functional programs. 
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A Appendix 

A rewriting rule for transforming a set of definite clauses consists of meta- 
atoms, where a meta-atom is an atom that includes &-variables and ^-variables 
instead of usual variables. An &-variable is a variable that begins with & (such 
as &AT) and can be replaced with an arbitrary (usual) term. A ^-variable is a 
variable that begins with ff (such as ffC) and can be replaced with an arbitrary 
(usual) variable. 

A rewriting rule is of the form (n > 0): 

{rulename): 

H,{Cs} — >■ {Esi}, Bsi; 

-T {ES 2 }, Bs2', 



Where {rulename) is the name of a rule, El is a, meta-atom, Cs is a (possibly 
empty) sequence of executable meta-atoms, Esi are (possibly empty) sequences 
of executable meta-atoms, and Bsi are (possibly empty) sequences of meta- 
atoms. H is called the head, Cs the applicability condition part, each Esi an 
execution part, and each pair of Esi and Bsi a body of the rule. The (rulename) , 
the condition part, and each execution part are optional. 

Assume that we are given an atom b in the body of a definite clause C. A 
rewriting rule of this form is applicable to the atom b iff the head H matches 
the atom 6 by a substitution 9 (i.e., E19 = b) and Csd is true (by the given 
evaluator). When the rule is applied to a clause C at an atom b, C produces less 
than or equal to n clauses. Each new clause is obtained, after Esi6 is executed 
successfully (by the given evaluator) with an answer substitution cr, by replacing 
ba in Ca with BsiOa. 
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Abstract. Equivalent transformation has been proposed as a method- 
ology for providing programs with appropriate data structures. For in- 
stance, logic programs which use lists are transformed into equivalent 
programs that use difference-lists. However lists and difference-lists are 
both usual terms and in this sense no new data structures are introduced 
in the transformation. Since logic programming has fixed data structure 
called terms, no one can develop theoretical foundations for introducing 
new data structures into programs as far as only logic programs are dis- 
cussed. In this paper we develop a theoretical foundation of equivalent 
transformation that introduces new data structures. We introduce a pa- 
rameter r for data structures, by which many languages with different 
data structures are characterized. By changing this parameter (say from 
A to A) we can discuss data structure change for programs. We define a 
concept of safe extension of data structures, and prove that the meaning 
of a program on a data structure is preserved by safe extension of the 
data structure. 



1 Introduction 

Equivalent transformation is one of the most important methods for improving 
efficiency of programs [O]. Declarative programs such as logic and functional 
programs may be improved into more efficient ones by using unfolding, folding, 
goal replacement, tupling, and other transformations. 

It is well known that efficiency of computation depends on data structures. 
In case of procedural programming languages, it is taken for granted to adopt 
better data structures for efficient computation m- Data structures are also 
important in logic and functional computation model. 

Equivalent transformation has been proposed as a methodology for providing 
programs with appropriate data structures. For instance, several methods for 
the transformation of logic programs which use lists into equivalent and more 
efficient programs that use difference-lists have been proposed in the literature 

m m- 
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However, it should be noted that lists and difference-lists are included in 
usual terms and in that sense no new data structures are introduced in the 
transformation. Theoretical foundation of such transformation is exactly the 
same as usual equivalent transformation of programs by unfolding, folding, goal 
replacement, and other transformation techniques. 

Extension of data structures in this paper is totally different. While the 
above methods transform logic programs into other logic programs with data 
structure unchanged in the sense that they both use terms, in our theory new 
data structures that are not included in the original domain are introduced in the 
transformation. Typical examples for such new data structures are class variables 
and domain variables, which are not included in usual term domain. Expressive 
power and efficiency is improved by using class variables based on sort hierarchy 
m- Many constraint satisfaction problems cannot be solved within practical 
time in Prolog, while constraint logic programs with domain variables solve them 
far more efficiently than Prolog |B|. 

In this paper we develop a theoretical foundation of equivalent transforma- 
tion that introduces new data structures, based on which we can often make 
programs more efficient. For instance, in the case of class- variables, improvement 
of efficiency of programs is obtained by the following equivalent transformations: 

1 . (ETi) introduction of class variables, 

2 . {ET2) transformation of programs using class variables. 

In the case of domain- variables, programs are similarly improved by the following 
two steps: 

1 . {ETi) introduction of domain variables, 

2 . {ET2) transformation of programs using domain variables. 

In both cases, introduction of new data structures (ETi) is essential to further 
transformation (ET2). 

The main purpose of the paper is to formalize the first equivalent transfor- 
mation (ETi). Since logic programming has a fixed data structure called terms, 
no one can develop theoretical foundations for introducing new data structures 
into programs as far as only logic programs are discussed. It is crucial to intro- 
duce a parameter T for many data structures, by which many languages with 
different data structures are characterized. Mathematical structure called a spe- 
cialization system is introduced as a parameter for specifying data structures 
in problem description. Declarative descriptions are also introduced on special- 
ization systems. A declarative description d on a specialization system E is asso- 
ciated with its meaning M{r,d). Equivalent transformation is a transformation 
of (T, d) preserving M(E,d). Then, we have two typical equivalent transforma- 
tions for a pair (T, d) of a declarative description d and a specialization system 
E: 



1 . ETi'. (Ei,d) — >■ (/2,d) Change from Ei into I2 with d unchanged, 

2 . ET2: {E,di) — >■ (T, d2) Change from di into d2 with E unchanged. 
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We define extension and safe extension of specialization systems to 
formulate introduction of new data structures. We also prove the correctness of 
equivalent transformation by safe extension of specialization systems, i.e., 
M{ri,d) = M{r2,d) 

for any Ji and l 2 such that I 2 is a safe extension of Fi. 



2 Efficiency Improvement by Class Variables 

2.1 A Vehicle Problem 

In order to discuss improvement of efficiency by introducing new data structures, 
consider a sample problem : 

Bicycles and cars are vehicles. There are two bicycles; “bikel” and 
“bike2.” There are three cars; “carl”, “car2”, and “mycar.” Vehicles 
have tires. Cars have doors. I own “mycar.” Find all objects that have 
tires and doors and that I own. 



2.2 Formalization by a Logic Program 

The above problem is formalized easily by a logic program and a query 
as follows: 

Pl = { vehicle{X) bicycle{X). 
vehicle{X) car{X). 
bicycleibikel) 
bicycle{bike2) 
car(carl) 
car{car2) 
car{mycar) 

has{Z, tires) ^ vehide(Z). 
has{Z, doors) -fr- car{Z). 
own{i, mycar) 

answer{Y) ^ has{Y, tires), has{Y, doors), own{i,Y). }. 
ql = answer{Z). 



2.3 Formalization by a Sorted Logic Program 

Since the sample problem is related to concepts such as vehicles, cars, and bicy- 
cles, it is natural to formalize it on the basis of a concept hierarchy. One such 
formalization follows: 

Ps = { vehicle D bicycle \ car 
bicycle 9 bikel \ bike2 
car 9 carl | car 2 | mycar 
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has{A : vehicle^ tires) -i— . 
has{B : car, doors) 
own{i,mycar) 

answer(Y) i— has(Y, tires), has{Y, doors), own{i,Y). }. 

qs = answer (Z). 

In the program Ps, “vehicle”, “bicycle”, and “car” are classes, and “bikel”, 
“bike2”, “carl”, “car2”, and “mycar” are instances. Capital letters such as Y 
and Z are variables. The expressions “A : vehicle'' and “B : car" are sorted 
terms (class variables), representing a vehicle A and a car B, respectively. 

The sorted program Ps consists of three declarations and four clauses. The 
knowledge of concept hierarchy is represented more compactly by declarations 
in Ps than by clauses in P^- The four clauses in Ps are also more concise than 
the corresponding clauses in Ps due to the use of class variables. 



2.4 Towards a Common Theoretical Foundation 

We already know that the second program Ps is more efficient than the first one 
Pl to answer the same queries {qs and qs) [ll2j . When given the first program 
Pl, we want to transform Ps into Ps for efficient computation. Two questions 
now arise: 

How is Pl transformed into Ps? 

How is the transformation justified? 

In this paper, such questions will be solved in a general setting. 

In the previous subsections, two formalizations, {Pl, qs) and (Ps, qs), have 
been discussed separately without common theoretical foundation. In the subse- 
quent sections, we will introduce a general framework, where the two formaliza- 
tions in the previous subsections will be re-formalized in a single framework. This 
is essential to establish efficiency improvement by equivalent transformation. 



3 Specialization Systems 

3.1 Definition of Specialization Systems 

Definition 1. A specialization system is a four-tuple {A,Q,S,p) of three sets 
A, Q and S, and a mapping /i : 5 — >■ partial _map{A) that satisfies the following 
requirements, where partial jmap{X) is the set of all partial mappings on X . 

1. Vsi,S 2 G 5,3s e 5 : p{s) = p{s 2 ) o^(si). 

2. 3s € S,ya € A : y{s){a) = a. 

3. GQA. 

Elements of A are called atoms. Elements ofQ are called ground atoms. Elements 
of S are called specializations. 
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When there is no danger of confusion, elements in S are regarded as partial 
mappings over A and the following notational convention is used. Each element 
in S is identified as a partial mapping on A, and the application of such a partial 
mapping is represented by postfix notation. For example, 9 € S and ^{9){a) are 
denoted respectively by 0 S 5 and ad. 

3.2 Examples of Specialization Systems 

Example B. A s-term is either a constant such as hike2 and a pure variable!!] 
such as A. A s-atom is an atom of the formp(<i, t 2 , ■ ■ ■ An), where p is a predicate 
and each ti is a s-term. Let Ab be the set of all s-atoms. Let Qb be the set of 
all ground (variable free) s-atoms. A binding 9 transforms an atom in Ab by 
replacing variables with s-terms. Let Sb be the set of all sequences of bindings. An 
element s in Sb transforms an atom in Ab into another atom in Ab by successive 
application of bindings in s, which defines the mapping ^b ■ Sb ^ map{Ab), 
where partial jmap{X) is the set of all mappings on X. Then Fb = {Ab, Qb,Sb, Pb) 
is a specialization system. 



Example D. A c-term is either a constant such as bikel, a pure variable such 
as Y, or a class variable such as B : vehicle. A class variable is a pair of a tag 
such as B and a class such as vehicle. Pure variables and class variables are 
called simply variables. A c-atom is an atom of the form p(ti, t^, - ■ ■ , tn), where 
p is a predicate and each U is a c-term. Let Ad be the set of all c-atoms. Let Gd 
be the set of all ground (variable free) c-atoms. 

Four kinds of basic specializations are introduced; a variable substitution 
such as {X,mycar), a tag renaming such as (B,C), a class restriction such as 
{C, bicycle), and a tag substitution such as (B,car2). 

A pure variable is specialized by a variable substitution. For example, Z 
is specialized to X : car by {Z,X : car). A class variable is specialized by 
a tag renaming. For instance, B : car is specialized to C : car by (B,C). A 
class variable is specialized by reducing its class into its subclass. B : vehicle is 
specialized to B : car by {B,car). A class variable is specialized to a constant 
in its class. For instance, B : car is specialized to mycar by (B,mycar). 

A basic specialization transforms an atom in Ad into another atom in Ad- 
Let Sd be the set of all sequences of basic specializations. An element s in Sd 
transforms an atom in Ad by successive application of basic specializations in s, 
which defines a mapping pd '■ Sd^ partial jmap{Ad) ■ Then Fd = {Ad, Gd, Sd, Pd) 
is a specialization system. 

Note that, among these four types of basic specializations, the last two basic 
specializations may not be applicable to some objects. For instance, basic spe- 
cialization {B, bicycle) cannot be applied to B : car. This is because bicycle is 
not a subclass of car. Similarly, basic specialization {B,carl) cannot be applied 
to B : bicycle since carl is not an element of bicycle. 

^ A pure variable is an ordinary variable, but we use this term to distinguish it from 
a class variable. 
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4 Declarative Description 

4.1 Declarative Description 

Definition 2. Let F be a specialization system {A,Q ,S, p) . A definite clause on 
r is a formula of the form: 

H •<— i?i , i?2 , • • ■ , Bn 

where H, Bi, B 2 , • • • , Bn are atoms in A. A declarative description on F is a set 
of definite clauses on F. 

Let C be a definite clause on X. The head of a clause C is denoted by 
head{C), and the set of all atoms in the body of C is denoted by body{C). 

A specialization s G 5 is applicable to a G A iff there exists b £ A such 
that p{s){a) = b. When 9 £ S is applicable to F[,Bi,B 2 , - ■ ■ ,Bn, a definite 
clause C9 = {F19 £- Bi9, B20, • • • , -B„0) is obtained from a definite clause C = 
{H £- Bi, B 2 ,‘ ■ ■ , Bn)- A definite clause C is an instance of C iff there is a 
specialization 9 such that C = C9. A definite clause C is ground iff it consists 
of only ground atoms. A ground instance of a definite clause C is a ground 
definite clause that is an instance of C. 

Let P be a declarative description on F. The set of all ground instances of 
definite clauses in P is denoted by Gdause{P). 

Example 1. Pl is a declarative description on Pf,. Pg is a declarative description 
on Fd- 

4.2 Meaning of a Declarative Description 

For a declarative description P, the meaning A4(P) is defined by 

M(p) = uZoiTpr(<^), 

where Tp is a mapping on the powerset 2®, which mapps a subset of Q into 
another subset of Q : 

Tp(x) = {head(C) | body(C) Cx,C£ Gclause(P)}. 

Since Gclause(P) and Tp depend on the specialization system P, M{P) also 
depends on P. Hereafter when P should be specified explicitly, Ai(P) will be 
denoted by A4(F,P). 

5 Increase of Meaning by Extension 

We consider two specialization systems Pi and P 2 , and discuss the relationship 
between the two meanings of a declarative description on the two specialization 
systems. 

5.1 Extension of Specialization Systems 

Consider a mapping p : S ^ partiaLmap(Ad) ■ The mapping p determines a 
subset p' of S X Ax A uniquely by 
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fi' = {{s, a, b) I s £ S,a £ A,b £ A, /i(s)(o) = b}. 

It is obvious that the mapping that determines /r' from fx is one-to-one. In this 
paper ^ will be identified with /i', thus ^ will be regarded as a subset of 5 x Al x Al, 
which is convenient for discussion of the relation between two specialization 
systems. 

Definition 3. Let A and l 2 be specialization systems: 

A = {A\,Qi,Si, fii) , 

A = (-42, 1/2, '52 7^2) • 

A is an extension of Fi (or A is a partial specialization system o/ A/^, 
iff Ai C A2, Gi C G2, A C S2, and C ^2- 

Note that fii and ^2 are regarded, respectively, as subsets of 5i x xli x Ai and 
A X -42 X -42, and that C ^2 iff any elements (1?, u, 6) in are included also 
in p 2 - 



Example 2. A is an extension of A- 



5.2 Inclusion Relation of Meaning 

The following theorem states that the meaning of a declarative description on a 
specialization system increases by extension of the specialization system. 

Theorem 1. Assume that A is an extension 0 / A- If P is a declarative de- 
scription on A, then P is also a declarative description on A, and 
M{Pi,P)CM(P2,P). 



6 Preservation of Meaning by Safe Extension 

6.1 Safe Extension 

Definition 4. Let A and A be specialization systems: 

A = (-4i,t/i, A,A/i), 

A = (-42, f/2, A, 1 / 2 )- 

A is a safe extension of A iff the following conditions are satisfied. 

P P 2 is an extension of Pi. 

2. Gi = G2 = G. 

3. For any finite subset X of Ai and for any specialization 9 in A such that 
X9 C G, there is a specialization u in A such that x9 = xa for any x £ X. 



Example 3. Pd is a safe extension of A- 
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6.2 Preservation of Meaning 

The following theorem states that the meaning of a declarative description on a 
specialization system is preserved by safe extension of the specialization system. 

Theorem 2. [Safe-extension Theorem] Assume that I 2 a safe extension 
of Fi. If P is a declarative description on Fi, then P is also a declarative de- 
scription on F 2 and 

M{FuP)=M{F2,P). 



7 Application of the Theorem 

Based on the safe-extension theorem, we discuss the equivalence between the 
declarative description Pr on the specialization system Fh and the declarative 
description Ps on the specialization system Fd- 

Since Ih is a safe extension of Ft,, we have, by theorem(21 

M{Fi,,PL)^M{Fd,PL). 



The three predicates vehicle, bicycle, and car, which are defined in the declar- 
ative description Pl on the specialization system Fd, can be represented more 
compactly by the following declarative description Pm, when we use the struc- 
ture of the specialization system Fd- 

Pm = { vehicle{A : vehicle) 
bicycle{A : bicycle) 
car{A : car) t— . 
has{Z, tires) ->r- vehicle(Z). 
has{Z, doors) ^ car{Z). 
own{i,mycar) 

answer{Y) 1 — has{Y, tires), has{Y, doors), own{i,Y). } 

Then, we have 
M{Fd,PL)=M{Fd,PM). 

Moreover, when we remove the body of has clause in the declarative descrip- 
tion Pm on the specialization system Fd by unfolding, and delete three clauses, 
{vehicle, bicycle, and car clauses), we obtain a declarative description Ps on the 
specialization system Fd and 

M{Fd,PM)-H = M{Fd,Ps), 

where, H is the meaning of the declarative description consisting of the three 
clauses; vehicle, bicycle, and car. 

Thus we have 

M{Fi,,Pl)-H = M{Fd,Ps). 

Therefore, 

{g I answer{g) € M{Fb,PL)} 
and 

{g I answer{g) G M{Fd,Ps)} 

are the same, and the representation change from l2.2l to I2.dl can be justified by 
the theory in this paper. 
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8 Conclusion 

Each theory in computer science has been usually discussed on one specific lan- 
guage with fixed data structure. Necessity of unified theoretical foundation for 
many languages with different data structures has not been widely recognized. 
In this paper, we first defined specialization systems and declarative descriptions 
on specialization systems. A problem was formalized as a pair of a specializa- 
tion system and a declarative description. The concept of specialization systems 
characterizes data structures for many languages, and is essential to develop a 
theory for introducing new data structures into problem descriptions. 

If we change a specialization system Ti into l2 with a declarative description 
d left unchanged, (A,d) is transformed into (/2,d). If /2 is a safe extension of 
Fi, the transformation from (Ti,d) to (/2,d) is an equivalent transformation, 

i.e., M{Fi,d) = M{F2, d). This theory can be applied to many examples of effi- 
ciency improvement by introducing new data structures, including class- variable 
examples and domain- variable examples. 
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Abstract. In formal synthesis methodology, circuit implementations are 
derived from specifications by means of elementary logical transforma- 
tion steps, which are performed within a theorem prover. In this ap- 
proach, additionally to the circuit implementation, the proof that the 
result is a correct implementation of a given specification is obtained au- 
tomatically. In the paper, we formally describe the functional semantics 
of system specifications in higher order logic. This semantics builds the 
basis for formal synthesis at system level. Further, theorems for circuit 
optimisation at this level are proposed. 



1 Introduction 

The most critical question in circuit synthesis is the correctness of the design: 
how can one guarantee the correctness of the automatically generated circuit 
implementation with regard to a given specification? The synthesis programs are 
too big and too complex to prove their correctness using the available software 
verification tools. 

In formal synthesis, the circuit implementation is obtained from the specifi- 
cation by application of elementary transformation rules which are formulated 
in higher order logic and proved as theorems in a theorem prover. The correct- 
ness of a transformation means a mathematical relation between the source and 
the result. If such correct transformations are used during the synthesis process, 
then, as a result, not only the circuit implementation, but also a proof of the 
correctness of this implementation with regard to the specification ( “correctness 
by construction”) is obtained. 

In the formal synthesis, most approaches deal with the synthesis of digital 
systems at lower levels of abstraction [S], or with synthesis of pure data-flow 
descriptions at the algorithmic level 0- 

Besides formal synthesis, there are approaches which can be summarized by 
the term “transformational design”. They also claim to fulfill the paradigm of 
“correctness by construction” : The synthesis process is also based on correctness- 
preserving transformations. However, the transformations are proved by paper 

* This work has been partly financed by the Deutsche Forschungsgemeinschaft, Project 
SCHM 623/6-3. 
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& pencil and afterwards implemented in a complex software program. It is im- 
plicitly assumed that an automatic synthesis process is correct by definition. But 
there is no guarantee that the transformations have been implemented correctly 
and therefore, the correctness of the synthesis process cannot be regarded as 
proved. A successfully applied approach for synthesis at the system level that 
falls into this category is described in |5]. 

2 Circuit Descriptions at the Algorithmic Level 

We have developed the language Gropius [T] to describe the circuit specifications 
and implementations in our approach to formal synthesis. 

The BNF below describes the syntactic structure of DFG-terms (acyclic Data 
Flow Graphs). They represent non-recursive programs that always terminate. 

varstructure ::= variable [“'.’’type] \ “(” varstructure var.structure “)” 
expression ::= varstrueture \ constant type ] 

I “(” expression expression “)” | “(” expression expression “)” 
DFG-term ::= “A” var^structure 

[ “let” var^structure = expression “in” ] expression 

A condition is a DFG-term, which produces a boolean output for an input of 
arbitrary type. We have fixed the following syntax in Gropius for program terms 
{P-term) which are used for circuit descriptions at algorithmic level: 

P-term ::= “DEFINED” DPG-term \ “WHILE” condition P-term 
I P-term “SERIAL” P-term \ P-term “PARALLEL” P-term 
I “IF” condition P-term P-term 

The P-terms have a type a /3 partial. To represent the data type of a P- 
term which may not terminate, the type a partial has been introduced. This type 
extends an arbitrary type a by a new value T : partial = T | Def of a. 

The functions resolve and resolve^ have been introduced in order to define 
new functions on single and paired values of type a partial, respectively: 

(resolve T / a a) A (resolve (Def x') j a^= f x) 

resolve^ (a : a partial) (& : /3 partial) (B : a x /3 ^ j partial) 
resolve a {Xu. resolve b (Xv. B(u,v)) T) T 

Below, we give the formal definitions for the semantics of the P-terms 
A SERIAL B and A PARALLEL B. More details about P-terms and the algo- 
rithmic level of Gropius can be found in |2]. 

Aof 

(A : a —>■ ,3 partial) SERIAL (B : /3 7 partial) = (Aa:. resolve (A x) B T) 

(A : a — ^ /3 partial) PARALLEL {B : a ^ 'y partial) (Xx. resolve^ (A x){B x) Def) 

The first definition says that (A SERIAL B) is a function which, for a given x : a, 
delivers the value T, if A a; = T, and it delivers the value B y, if A x = Def y. 
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Similarly, {A PARALLEL B) is defined as a function which, for a given x : a, 
delivers _L, if A x = _L or i? a; = _L, and it delivers the value Def(y, z), if 
A X = Def y and B x = Def z. 

An algorithmic description expresses the functional dependencies of outputs 
on the inputs of the circuit. It does not take time aspects into account. During 
high-level synthesis the algorithmic description is mapped to a register transfer 
(RT) level structure. To bridge the gap between these two different abstraction 
levels one has to determine how the circuit communicates with its environment. 
Therefore, as a second component of the circuit representation an interface de- 
scription is required. The interface description defines the temporal signal behav- 
ior at the circuit interface and specifies exactly the communication of the circuit 
with the environment. In contrast to most existing approaches, we strictly sep- 
arate between the algorithmic and the interface description. We provide a set 
of interface patterns, of which the designer can select one. More details about 
interface patterns can be found in m- 

3 Circuit Descriptions at the System Level 

Below we give the definitions for the syntax and semantics of system descrip- 
tions called here System-structures or S-structures for short. In our approach 
to synthesis at system level, all the processes interact via a fixed communica- 
tion scheme which is label-based and inspired by higher order Petri nets [B]. 
Our process corresponds to a Petri net transition with some places as its inputs 
and outputs. “Firing” means here removing the input labels, performing some 
calculation and delivering the result as a new label to the output places. 

At the system level, processes communicate via channels. They have a fixed 
structure and consist of three signals: a signal data of arbitrary type a, and two 
boolean control signals data-valid and ready. Each channel has a fixed direction, 
which is defined by the direction of the signal data. The datajaalid-sigTiAL goes 
to the same direction whereas the read^Z-signal goes to the opposite direction. 

In channels, communication is performed via handshake. Let us consider a 
channel from a process A to a process B. A signals via data_valid that there is a 
label with some data being on data. Process B signals via ready that it is ready 
to read the next label. Whenever both data^valid and ready become true, the 
communication takes place, i.e. the label is moved from A to B. 

Four kinds of processes will be used as components in S-structures: DFG-term 
and P-term based processes, K-processes (see Section U]) and S-calls. The DFG- 
and P-term based processes are essentially nothing else but circuit descriptions 
at the algorithmic level. The only difference is that the functional description is 
combined with a special interface pattern for the system level. Both DFG-term 
based processes and P-term based processes have a single input channel and a 
single output channel. K-processes are a sort of a glue logic for building arbitrary 
S-structures and for managing the communication (German: Kommunikation) 
between other processes. They may have an arbitrary (but fixed) number of input 
and output signals and are used to spread, combine, buffer, delay or synchronize 
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signals. Finally, S-calls are nothing else but procedure calls. One can define (non- 
recursive) S-structures and give them arbitrary names. S-processes allow the use 
of hierarchical circuit descriptions in Gropius and reduce the complexity of the 
synthesis process. The syntax of S-structures is as follows: 



interface 

DFG-process 

P-process 

S-call 

S-process 

K-process 

S-structure 

S-definition 



“(” channel | channel } “)” 

“Dfg_proc” DFG-term interface 
“P_proc” program interface 
structure-name interface 

DFG-proeess \ P-process \ K-proeess \ S-call 
(“Double” I “Join” | “Synchronize” | “Split” | “Fork” 
I “Choose” I “Sink” | “Source” constant ) interface 
“3” I channel } S-process { A” S-process } 
structure-name interface “=” S-structure 



On system level, in contrast to all other Gropius specifications, S-structures 
are described relationally, as it is desirable and necessary to permit cycles at the 
system level. 



4 K-Processes 

We have defined eight elementary K-processes in Gropius: Double, Join, Split, 
Synchronize, Fork, Choose, Source, and Sink. In K-processes, no calculations on 
data labels are performed. Labels are solely moved according to the label based 
communication pattern presented in the previous section. 

The K-process Double duplicates the input label. Join combines two separate 
labels into a single paired label. Split is the inverse process to Join. 

The K-process Synchronize collects two labels. As soon as both successor 
processes are ready, both labels are given over simultaneously. 

The K-process Fork delivers the first component d of an incoming label {d, b) 
of type a x bool to one of the output channels, depending on whether the second 
component of the label is false or true. 

The K-process Choose has two input channels ini and iu2 for labels of type 
a X bool and one output channel out for labels of type a. It is the only process, 
which can fire even if not all inputs are ready; moreover, the channels ini and 
m2 can never be ready simultaneously. Choose delivers to its successor the first 
value d of the label (d, b) it became either from ini or in2- There are two different 
states, Readyj^ and Ready2, in which Choose can fire. Initially, Choose is in the 
state Readyj^. In the state Ready^, only channel iui is ready. Every time a data 
label (d, b) occurs, firing delivers the label d to the output channel out; it leaves 
the state unchanged, if 6 = T, or changes it to Ready3_^, if 6 = F. 

The process Source C is a source in the data fiow which does not have input 
channels and yields the constant C every time when the output channel is ready 
to receive a signal. The process Sink has one input channel but no output channels 
and implement a sink of a signal. It is always ready to read a label from their 
input channel. That means, a label can always leave the predecessor process and 
move to Sink where it disappears afterwards. 
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5 Functional Semantics of S-Structures 

In [2, we have defined the behavioral semantics and the equivalence relation 
for S-structures, which consider the temporal input-output signal behavior. 
But, an exact definition of the signal flow in time, as given in the behav- 
ioral semantics, is often not desirable. To take the purely functional aspects 
of the system descriptions into account, we will define the functional seman- 
tics and the functional equivalence relation for S-structures. Informally, the 
functional semantics of an S-structure fixes only the sequences of the output 
signals for the given sequences of input signals. We represent these (finite or 
infinite) signal sequences in the theorem prover HOL as values of the type ab- 
straction asignal, which are functions / of type (num a partial) satisfying 

def 

the following signal condition: ls_signal / = \/n.{fn = _L => Idle/n), where 

Idle / n Vfc. {n < k ^ {f k = _L)). Here, the value _L can be interpreted as the 
absence of any signal value. Using the type definition package by Melham [S] we 
have defined a representation function from_signal : a signal — )■ (num — a) and 
its inverse abstraction function to_signal, so that the following theorem holds: 

h (Va; : a signal. to_signal (from_signal x) = x) A 

(V/ : num — ^ a partial. Is_signal / = (from_signal(to_signal /) = /)) 

An example of a signal is the signal blank from_signal (An. _L). In order to 
build new signals from existing ones we introduce two operators A (for single 
value signals), and (for paired value signals): 

A {x : a signal) (A : a — >■ /3 partial) (0 : num) resolve (from_signal x 0) A _L 
Ax A (sue n) resolve^ {Ax A n)(from_signal x (SUC n)) (A o SND) 

(x : a signal)(y : [3 signal)(i3 : a x P ^ j partial) (0 : num) 
resolve^ (from_signal x 0)(from_signal y 0) B 

A^ X y B (SUC n) resolve (A^ x y B n) 

{\z. resolve^ (from_signal x (SUC n))(from_signal y (SUC n)) B) _L 

Both operators A and A^ yield functions of natural argument satisfying the sig- 
nal condition, i. e. h Vx A.Issignal{A x A) and h \/xyB. Issignal{A^ xy B) 
hold and hence two signal transformers APPLY and APPLY^ can be defined: 

APPLY A X to_signal(A x A) APPLY^ B x y'^= to_signal(A^ x y B). 

The functional equivalence of S-structures introduced below does not take 
into account the time when signal values are emitted or received. It ignores 
the names and the values of the intermediate signals as well. The functional 
semantics |P] of an S-structure P is a boolean higher order function. Its input 
and output parameters are (abstractions of) signal values of the type a signal. 

Hpf 

II P_proc(P : a /3 partial) || (x : asignal,y : /3 signal) = {y = APPLY P x) 
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II Dfg.proc / II (a; : asignal, 2 / : /^signal) = (y = APPLY (Def o /) a;) 

def 

II Double II (a; : asignal,yi : o;signal,j/2 : asignal) = (yi = a;) A (?/2 = x) 

II Split II (a; : (a X /3) signal, yi, 1 / 2 ) 

(yi = APPLY (Def o FST) a;) A (7/2 = APPLY (Def o SND) a;) 

II Join II (xi : a signal, X2 : /? signal,?/) {y = APPLY^ Def xi X2) 

II Synchronize || {x\ : a signal, a ;2 : /3 signal, ?/i : a signal, ?/2 : /3 signal) 

(2/1 = APPLY^ (Def o FST) xi X2) A ( 2/2 = APPLY^ (Def o SND) xi X2) 

To define the functional semantics of the K-process Fork we have introduced 
an auxiliary function ForkLen. ForkLenix : (a x bool) signal)n delivers a pair 
(hth) of natural numbers where h{l2) is the number of truth values F (resp.T) 
in the sequence SND(from_signal x 0), . . . , SND(from_signal x n). 

II Fork II {x : {a X bool) signal, 2/F : asignal,2/T : asignal) 

(Vn. let {Ip, I t) = ForkLenxn in resolve (from_signal x n) (Def o FST = 

(Az. if SND z then from_signal 2 /t(^t ~ 1 ) else from_signal ypilp ~ 1 ))) 
(ldle(from_signal yF)lp) A (ldle(from_signal yT)lT)) A 
let 0 = (An. 0) in ((FST o [ForkLen x) = 0 ) [yp = blank)) A 
((SND o [ForkLen x) = 0 ) [yp = blank)) 

To define the functional semantics of the K-process Choose we have intro- 
duced two auxiliary functions ChoiceLen and Choice. A call ChoiceLennxy 
delivers a triple [nextready, hjh), where nextready = T iff the first input chan- 
nel is ready after n -F 1 firings of Choose on input channels x and y, and li and 
I2 are the numbers of values read from x and y, resp., after these n -F 1 firings. 

def 

Choice (0 : num) (x : (a x bool) signal) [y : [a x bool) signal) (z : a signal) = 
resolve (from_signal z 0) 

(Az. resolve (from_signal X 0)(Ap. z = FST p) F)(x = blank) 

Choice (sue n) x y z‘= let [nextready, I2) = ChoiceLen n x y in 
let s = if nextready then from_signal x li else from_signal y I2 in 
resolve (from_signal z (SUC n)) (Az. resolve s [Xp. [z = FST p)) F) 
(ldle(from_signal x)li) A (ldle(from_signal 2/(^2) 

II Choose II (x : (a X bool) signal, y : [a x bool) signal, out : a signal) 

(Vn. Choice n x y out) A ((Vn. FST(C'/iofceLen n x y)) =F (2/ = blank)) 

def 

II Source [C : a) || [out : a signal) = (Vn. (from_signal out n = Def C)) V 
[3m. Vn. (from_signal out n = if n < m then Def C else J_)) 

II Sink II [in : a signal) T 
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The functional semantics of an S-structure 5 = 3 6 . S'! A . . . A S'„ is defined by 

dpf — 

II 5 II =3 6. II S'! II A ... A II S'n II . We call two S-structures and S 2 functional 
equivalent, if their functional semantics are equal: 5'i ~ S 2 || (S'! || = || S 2 ||. 



6 Program Transformations 



In what follows we present some functional equivalence theorems which can be 
considered as Gropius program transformations and build the basis for circuit 
combining/partitioning algorithms. All of the theorems have been proved in the 
theorem prover HOL |4]. 

h 3 (r : (a X bool) signal)(s : a signal). Dfg_proc {Xx. {x, T)){in, r) A 
Fork (r, s, out) A Sink(s) 

Dfg_proc (Aa;. x){in : a signal, out : a signal) 

In transformation o we took advantage of the fact that channel r can contain 
only sequences of the signal values Def(a:,T) or _L. 



h 3 (r : a signal). Source C (r) A Join (r, m : /3 signal, out) 
Dfg.proc (Xx : f3. {C,x)){in, out : (a x /3) signal) 



( 2 ) 



We use the transformation (|2j for elimination of K-processes Source by con- 
stant propagation. 



h 3 r s. Double {x : a signal, r, s) A P_proc A (r, u) A P_proc A (s, v) 
3 (t : /3 signal). P_proc (A : a —?■ partial) (x, t) A Double (t, u, v) 



( 3 ) 



By the application of theorem dl the double execution of a P-process is 
avoided: two copies are combined into a single one. Theorem (S) allows to com- 
bine two P-processes, which are executed in sequence, into a single P-process, 
or to partition a given P-process into two successively executed P-processes. 



h (3 u. P_proc A (x, u) A P_proc B (u, y)) ~ (P_proc (A SERIAL B) (x, y)) (4) 

Theorem © describes the functional equivalence of an S-structure consisting 
of two parallel P-processes, whose results are combined over a K-process Join, to 
a structure where first the two inputs are combined using Join into a single value 
which is then forwarded to a single P-process. With the help of this theorem a 
P-process can be partitioned into two parallel ones or two different P-processes 
can be combined to a single one. 
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h (3u t!. P_proc A (o;,m) A 9 -proc B {y,v) f\ }o\r\{u,v, z)) 



(3 w. Join(x, y, w) A P.proc ((A o FST) PARALLEL {B o SND))(u>, z)) 



( 5 ) 



7 Conclusion 

We have presented a method for the formal synthesis at the system level. In 
our approach, systems are described as structures of concurrent processes. The 
synthesis of correct circuit implementations is performed by means of equivalent 
transformations, which correspond to the application of theorems in the theorem 
prover HOL. For the proof of the correctness of transformations, the functional 
equivalence relation on process structures has been introduced and theorems 
about correctness of some optimising transformations have been proved. While 
the behavioral equivalence of S-structures introduced in [3] takes the exact tem- 
poral behavior of the circuit into account, the functional equivalence considers 
only the functionalities of the underlying processes. 
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Abstract. In this paper we introduce a methodology of program syn- 
thesis for Java programming language by extending Java classes with 
high level specifications. The specifications are handled by a distributed 
synthesizer also briefly described in this paper. 



1 Introduction 

The number of ready to use software components grows and software designers 
are faced with the fact that soon they are unable to have an overview of all 
software libraries. To solve this problem, we should use automated software de- 
sign, where software libraries are handled automatically with the help of software 
specifications provided by a designer. 

One way to automate the software design process is to use Structural Syn- 
thesis of Programs (SSP) [T]. SSP is a technique of deductive synthesis of pro- 
grams based on automatic proof search in intuitionistic propositional calculus. 
The solving complexity is hidden from the end-user into the system. The idea 
of using SSP for automated program generation is not new. Already in seven- 
ties a Priz family of programming languages was developed in the Institute of 
Cybernetics, that allows engineers to solve their tasks using a very high-level 
programming language. A similar approach has justified itself quite well in the 
Amphion system [^. 

In this paper we introduce a methodology of extending Java programming 
language with capabilities of SSP. This methodology helps us to cut down the 
programming time and expenses, and decreases the amount of possible faults 
as the actual software is generated automatically. We aim to create a new tool 
that adds to the Java language declarative specifications that are used for auto- 
mated program construction. Our ultimate goal is to increase the programming 
efficiency through the use of general solvers for variety of problems and software 
reuse. So we move towards the future’s realm, where a programmer needs only 
to specify what the program should perform, not how it should do it. 

* This work was partially funded by Estonian Innovation Foundation under the con- 
tract No. 6kl/00. 
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The Java language was chosen to be the platform for the SSP addition be- 
cause of its relative robustness and flexibility. Combining it with CORBA tech- 
nology m provides us with more flexible and concurrent computing in a network 
and forces to follow the ideas of modular programming. 

When applying the SSP to Java we have the following in mind: 

— Prototyping — no need to implement the (efficiently working) algorithms in 
the early phase of program development, as the system would take care of 
it automatically. 

— Software reuse — by applying the declarative specifications to the existing 
Java classes we can automate their reuse by letting the system handle the 
search for suitable components for the software. 

In Sect. 2 we give a general overview of the extended specification language, 
using an example to highlight its main features. The architecture to carry out 
the automated program construction process using distributed object model is 
proposed in Sect. 3. In Sect. 4 we briefly discuss the working principles of the 
Planner that is the heart of the automated program construction. 

This work is inspired by the work done in the Institute of Cybernetics, Esto- 
nia during several decades and related also to the work of Sven Lammerman |4] 
from Royal Institute of Technology, Sweden. 



2 An Example and the Specification Language 



In the current section we will use a modeling of radar coverage as an example. 
When starting to model something, we usually take a handbook of the held of 
interest and study it. When the area of interest is radar performance calculation 
the main equation that can be found is: 






PtG^X^aF 

{ATrfSNR^i^LN' 



( 1 ) 



where Pt is transmit power, G is antenna gain, A is wavelength, a is target 
radar cross section, F is pattern propagation factor, SNRy^in is minimal signal 
to noise ratio for target detection with certain probabilities, L is signal losses, 
N is total received noise and R is detection range. It is obvious to include the 
same components into our model. So we create a new Java class called Radar 
and declare the listed components. 

We add a declarative specification to the Java class that describes the rela- 
tions (constraints) among the components. The declarative specification is added 
to a Java class as a string array SSPspec, where every string represents a single 
declaration, also called as clause. 

In the specification we have to redefine all the components (Java variables 
and objects) of the class (statements starting with var or vir), that would be 
used in the relations (statements starting with keyword rel). A sample class of 
a radar, extended with a structural specification, is shown on Fig. [T] 
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public class Radar implements SSPinterface { 

public static String [] SSPspec = { 

"var r, wavelen : any", // detection range, wavelength 

"var pt , prf , rest : any", // power, pulse rep. freq. , target size 

"var g : any", // antenna power gain 

"var ppf : any", // Pattern Propagation Factor 

"var snr_min : any", // minimal Signal to Noise Ratio 

"var losses : any" , // system losses 

"var noise : any", // total noise power 

"rel r“4 = pt * g~2 * wavelen*2 * rest * ppf "+ 

" / ((4*pi)~3 * snr_min * losses * noise))", 

"rel snr_min.prf == prf", 

"rel noise. r == r" , 

"rel noise. prf == prf", 

>; 

Length r, wavelen; 

Integer pt , prf , rest ; 

Gain g; 

Noise noise; 

Losses losses; 

Ratio snr_min; 

Pattern ppf ; 



Fig. 1. Class Radar 



Note that the components specified as of type any have to be actual com- 
ponents of the Java class and their type is determined from class declarations. 

In the class Radar there are two types of relations present: equation and 
equivalences. Two components are equivalent when their evaluation is always 
the same during a computation. Our system includes an equation solver, hence 
we can use equations as relations in the specification. 

The first component r is of class Length and denotes the range from radar 
to target. The class Length is represented in Fig. E] In the SI (System Interna- 
tional) length is measured in meter (m). The class Length supports automatic 
transformation of units (length measured in other units can be automatically 
translated into meters.). By default the length is in meters {var component of 
the class Length). 

There is a special usage for having only one var component in a class: in 
such case we can use this object in relations without specifying its component to 
be used. The var component is automatically substituted instead of the whole 
object. This is used for example in the case of components of class Length in 
the equivalence specification of class Radar. There we write "rel noise. r == 
r" instead of "rel noise. r.m == r.m". 

The relations specify the conversion rules among the components. In the class 
Length all the relations are equations that can be treated as two-way translation 
rules. For example clause rel m/1000 = km can be treated as two methods. One 
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public class Length implements SSPinterface { 

public static String [] SSPspec = { 

"var m : any", // main measurement unit in SI 
"vir km, nmi, cm : any", // other units 
"rel m / 1000 = km", 

"rel m / 1852 = nmi", 

"rel m = cm / 100", 

>; 

Float m, km, nmi, cm; 

public void Length (Float number. String component) { 
if (component . equals ("m") ) m = new Float (number) ; 
else if (component . equals ("km") ) km = new Float (number) ; 
else if (component . equals ("nmi") ) nmi = new Float (number) ; 
else if (component . equals ("cm") ) cm = new Float (number) ; 

> 

} 

Fig. 2. Class Length 



allows to calculate m from km and another km from m. In the similar manner 
we can define classes for other components of class Radar. 

In order to use the specifications we have to include a component of the 
class Radar in another class (let us call it RadarC over age (see Fig. |3). Now 
we have to evaluate some of it’s components (see the constructor in class 
RadarC over age) and invoke a method compute of class SSP. A synthesizer (see 
Sect. 3) is then executed. It searches for a way of computations to find values for 
all var components of that object unless we explicitly specify what components 
should be calculated. The synthesizer uses the declarative specification given in 
classes that implement the SSPinterface. 

Similar methodology has been used in a radar coverage modeling package in 
a programming environment NUT j^. Experiments show that the methodology 
is suitable for solving this kind of problems. 



3 The Distributed Synthesizer 

Composing a distributed application — an application composed of distributed 
components — adds the following features: 

— Higher flexibility — as the components are not compiled into the application, 
the changes in the components do not affect the consistency of the distributed 
application if the interfaces of these components are fixed and semantics of 
their inputs and outputs remains unchanged. 

— Higher fault-tolerance — if a distributed component is developed for a certain 
environment and is well tested to work properly in it, then composing an 
application using these distributed components, that reside always in their 
native environment, cuts down in programming and testing time. 
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public class RadarCoverage implements SSPinterface { 
public static String [] SSPspec = { 

"var radar : any" , 

"vir ver_cov : any" , 

"rel [radar ,hor_ang, radar .ver_ang -> radar. r]" 

+ "-> ver_cov {CalcVerCov}-" 

>; 

Radar radar ; 

Coord [] ver_cov; 

public void RadarCoverage () { //The constructor 
radar = new Radar () ; 

radar . wavelen = new Length(3.25, "cm"); 

// other initializations in the same way 

> 

public static void mainCString [] args) { 

RadarCoverage model = new RadarCoverage () ; 

SSP . compute (model , "ver_cov"); //Invoking the synthesizer 

> 

public Coord [] CalcVerCovO { //Calculates vertical coverage diagram 
//method body 

} 



Fig. 3. Class RadarCoverage 



In a distributed application the intercomponent communication is fairly expen- 
sive in terms of time and other resources [^. Thus components are encouraged 
to be larger. We propose an architecture of the synthesizer, which is decomposed 
into 6 logically separated components: Knowledge Base (KB), Compiler, Decora- 
tor, Planner, Code Generator and Component Repository. The interconnections 
between these components are presented in Fig. SI 




In the class RadarC over age we have a relation that specifies how to cal- 
culate a radar vertical coverage. For vertical coverage calculation a method 
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CalcVerCov can be used as soon as a subtask that calculates component r 
of radar from given vertical and horizontal angle and other components that 
were evaluated before, is solvable. The method forms a vertical coverage dia- 
gram using this subtask in a loop for calculating the maximal detection ranges 
for several elevation angles. 

The task of the Compiler is to parse declarative specifications and store 
the results into a KB. The KB represents a memory system designed to hold 
data structures being used later for planning structure creation. It manages SSP 
specifications. 

The Decorator creates a special structure suitable for fast planning, sets 
evaluation states of components on the created structure and passes it all to the 
Planner. 

The Planner (see Sect. 4) is used for automatic program synthesis from prob- 
lem description. As a result of planning we get an algorithm that is not neces- 
sarily the shortest, however it does not contain unnecessary relations. 

If the solution is found, class code is generated by the Code Generator. The 
code is then compiled to Java class and added to the Component Repository. 

The aim of Component Repository is to maintain a set of components solving 
a certain problem. The components can be reused to solve similar tasks when 
the problem description is matching. 

The Compiler, the Decorator, the Planner and the Code Generator access 
the KB to set and get information needed during specification processing. 

4 The Planner 

The Planner uses SSP and the proof search algorithms proposed in |Z]. 

The declarative specification is located in the KB — a special structure to 
store descriptions of all objects (components of the context where planner was 
invoked) and all relations (computability statements), describing dependencies 
between objects. Two kind of relations may occur in the declarative specification: 

— Unconditional relations implementing unconditional computability state- 
ments of SSP. In such relations computability of some (output) objects de- 
pends only on some other (input) objects. Unconditional relations of several 
types as equations, equivalences, Java methods etc. are available in the spec- 
ification language. 

— Relations with subtasks implementing conditional computability statements 
of SSP. Such relations describe more sophisticated dependencies where out- 
put objects depend not only on input objects but also on solvability of some 
other computing problems. 

The problem specification is of form x — > y, where x denotes the set of known 
objects and y denotes the set of objects to be computed. The Planner has to 
construct an algorithm (a sequence of relations) that describes how to compute 
y from x. 

The proof search strategy of SSP applied in the Planner is: 
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— an assumption-driven forward search to select unconditional relations (linear 
planning). The algorithm works in the forward direction and only uncondi- 
tional relations are considered. At starting point all the objects that are 
inputs for the current problem are set as known objects. At each step, if all 
the input objects of the relation are known and at least one output object 
in not known, the relation is added to the synthesizable algorithm. After 
using relation to the synthesizable algorithm all its output objects are set 
as known objects. The search is a simple flow analysis on the network of 
unconditional relations. 

— a goal-driven backward search to select and solve subtasks. The search is 
applied if the assumption-driven forward search is not sufficient. Only such 
relations with subtasks are considered which input objects are known. The 
Planner is recursively used for solving every subtask of the relation. If all the 
subtasks of the relation are solved, the relation is added to the synthesizable 
algorithm. Linear planning is used after every invocation of a relation with 
subtasks in the algorithm. 

— a minimization is applied to the synthesized algorithm. Using search strate- 
gies mentioned above does not guarantee that we have built the shortest 
possible algorithm for computing the desired goal. Even more, the synthe- 
sized algorithm may contain relations that are not necessary for computing 
the goal. Minimization is used to exclude such relations from synthesized al- 
gorithm. As a result of planning we get an algorithm that is not necessarily 
the shortest, but it does not contain unnecessary relations. 



5 Concluding Remarks 

In the current paper we propose an extension to the Java language that increases 
the programming efficiency through the use of general solvers for variety of 
problems and software reuse. 

We also propose an architecture for the synthesizer, that performs the auto- 
mated program construction. 

Our main objective is to extend a distributed programming language with 
SSP capabilities that automates software reuse and helps users to design pro- 
grams. We intend to create a tool that allows engineering modeling, prototyping, 
flexible networking, and connections among different software components de- 
signed and written for different platforms. 

We use a distributed object model that increases the flexibility of particular 
system and provides higher flexibility and fault-tolerance. 
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Abstract. Formal descriptions of syntax are quite popular: regular and 
context-free grammars have become accepted as useful for document- 
ing the syntax of programming languages, as well as for generating effi- 
cient parsers; attribute grammars allow parsing to be linked with type- 
checking and code generation; and regular expressions are extensively 
used for searching and transforming text. In contrast, formal semantic 
descriptions are widely regarded as being of interest only to theoreticians. 
This paper surveys the main frameworks available for describing the 
dynamic semantics of programming languages. It assesses the potential 
and actual uses of semantic descriptions, and considers practical aspects, 
such as comprehensibility, modularity, and extensibility, which are espe- 
cially significant when describing full-scale languages. It concludes by 
suggesting that the provision of mature tools for transforming practical 
semantic descriptions into reasonably efficient compilers and interpreters 
would significantly increase the popularity of formal semantics. 

The paper is intended to be accessible to all computer scientists. Famil- 
iarity with the details of particular semantic frameworks is not required, 
although some understanding of the general concepts of formal semantics 
is assumed. 



1 Introduction 

> Formal syntax is widely used in practical applications. 

Formalisms for specifying the syntax of programming languages originated from 
theoretical studies of automata and parsing. They have subsequently been found 
useful in various practical applications. For instance, tools such as lex and yacc 
generate scanners and parsers from regular, resp. LALR(l) context-free gram- 
mars; the ASF -hSDF Meta-environment [14] generates efficient parsers from un- 
restricted context-free grammars [8]; compiler- writing systems such as Eli [30] 
generate type-checkers and code-generators from attribute grammars; and ed- 
itors such as vi and emacs support the use of regular expressions to search 
efficiently for (and replace) particular patterns in text. 



D. Bj0rner, M. Broy, and A. Zamulin (Eds.): PSI 2001, LNCS 2244, pp. 165—190, 2001. 
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> Formal semantics is seldom used in practical applications. 

In marked contrast to the popularity of formal syntax, formal semantic descrip- 
tions have seldom been exploited in practical applications concerning design and 
implementation of programming languages. As we shall see in Sect. 2, there is 
no shortage of semantic frameworks to choose from, nor has there been a lack 
of theoretical effort in establishing the foundations of the various frameworks. 
The major semantic frameworks have also been quite widely taught (even at the 
undergraduate level) and plenty of pedagogical text-books are available. The 
potential benefits of using formal semantics in general, as well as the special ad- 
vantages of particular frameworks, have been proclaimed in numerous books and 
papers. Yet despite all this investment of effort in promoting formal semantics, 
significant practical uses of semantic descriptions have been rather few and far 
between. 

> We shall survey the various semantic frameworks, list some uses that have 
been made of them, and speculate on the hindrances for greater use. 

Our survey of semantic frameworks in Sect. 2 will be deliberately brief and su- 
perficial, focussing on the most important differences between the frameworks, 
and ignoring many details. In Sect. 3 we list the potential uses of formal seman- 
tics, and indicate some of the more interesting actual uses. Section 4 considers 
various hindrances to greater use of semantic descriptions. 

t> Our conclusion will be that wider use of formal semantics depends on the 
availability of tools for generating (reasonably efficient) implementations 
from semantic descriptions. 

Some frameworks may appear to be inherently better-suited for generating effi- 
cient implementations. For instance, it might be imagined that operational se- 
mantics would have decisive advantages over the more abstract denotational and 
axiomatic approaches. However, any kind of semantics is supposed to determine 
the observable behaviour of all programs in the described language; provided 
that the relevant information about behaviour can be extracted automatically 
from the semantics, the generation of implementations from that information 
may be largely independent of how it was originally presented. In general, the 
efficiency of the generation process itself may well be unimportant compared to 
the efficiency of running programs via the generated implementation. 

> Few such tools are currently available. 

Currently, very few systems generating any kind of implementation from seman- 
tic descriptions are available [25]. Most of the semantics-directed compiler and 
interpreter generators reported in the literature were developed in the 1980’s, 
and remained as prototypes with limited support and maintenance. 



> Few semantic descriptions have good pragmatic features. 
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The use of even a properly-implemented and well-maintained system is limited 
to the input available for it. Here, the input should be complete, fully formal 
semantic descriptions — in marked contrast to the kind of semantic description 
usually found in textbooks and papers, where “obvious” details are often omit- 
ted, and semi-formal “conventions” are introduced in the interests of conciseness. 
Good pragmatic features, such as modularity and readability, are needed for ef- 
ficient development and use of semantic descriptions, but are sadly lacking in 
most frameworks. 

t> The main points of this paper are all displayed like this. 

For a quick first reading, one may prefer to focus on the main points and il- 
lustrative examples, skipping most of the intervening text. It is hoped that the 
display of the main points (following Alexander [3]) does not significantly hinder 
a continuous reading of the entire text. 



2 Formal Semantics 

To start with, let us distinguish between static and dynamic semantics: 

> Static semantics concerns checking for well-formedness. 

For languages intended to be implemented by compilers, the well-formedness of 
every part of a program should be checked before starting to run the program, 
in general. The static semantics of a program corresponds to its compile-time 
behaviour, and is independent of any input that is provided to the program 
at run-time. Well-formedness is usually decidable, so static semantics may be 
treated as a kind of (context-sensitive) syntax, and specified by attribute gram- 
mars. 

> Dynamic semantics is about computation. 

For compiled programs, their well-formedness has already been checked, and 
their dynamic semantics corresponds just to their run-time behaviour. For lan- 
guages implemented by interpreters, programs are usually run without a forego- 
ing overall well-formedness check, and any required checks happen at run-time, 
thus being considered part of dynamic semantics. 



> In this paper, the focus is entirely on dynamic semantics. 

Static semantics is usually an essential ingredient in complete language descrip- 
tions, and an interesting topic in its own right. Unfortunately, it is outside the 
scope of the present paper. Note however that static semantics (especially for 
type-checking and type-inference) appears to be used more often in practical 
applications than dynamic semantics is. 
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t> Most frameworks for dynamic semantics can be classified as operational, 
denotational, or axiomatic. 

In operational frameworks, the semantics of a program is specified as an abstract 
machine or transition system, the computations of which represent possible exe- 
cutions of the program. A denotational semantics is given by inductively-defined 
functions mapping each program to an abstract entity representing its observ- 
able behaviour, and each part of a program to an abstract entity representing its 
contribution to that behaviour. Axiomatic semantics involves rules for deducing 
assertions about the correctness or equivalence of programs and their parts. 

We survey the main frameworks that have been developed within each of 
the above classifications, and briefly consider a proposal to develop complemen- 
tary descriptions. A few frameworks do not fall into these classifications, being 
essentially hybrids of different kinds of frameworks. 



> Most semantic frameworks are based on context-free abstract syntax. 

Use of abstract syntax implies that semantics is defined for trees that directly 
reflect the actual compositional structure of programs. Concrete syntax, with the 
issue of how to parse a program text so as to discover its structure, is thus of no 
concern in semantic descriptions. Of course, a complete language description has 
to specify the exact relationship between concrete and abstract syntax — which 
may sometimes be not so straightforward, especially when concrete syntax has 
been specified with a restricted kind of grammar, such as LALR(l). Context-free 
abstract syntax is particularly pleasant to work with, and has clean and simple 
algebraic foundations. 

In most semantic frameworks, abstract syntax is specified by ordinary BNF- 
like grammars — the terminal symbols being as in concrete syntax, but here used 
merely to distinguish between the various abstract constructs. Using the same 
terminal symbols makes it easy to guess the intended relationship between con- 
crete and abstract syntax, and generally facilitates the reading of semantic de- 
scriptions. However, such abstract syntax grammars are always interpreted as 
defining sets of trees, rather than sets of strings. These grammars tend to be sig- 
nificantly simpler than the corresponding unambiguous context-free grammars 
for concrete syntax — in particular, they may have significantly fewer nonterminal 
symbols and chain-productions. 



t> We shall illustrate the various semantic frameworks with fragments involving 
the description of a simple if-statement and an assignment expression. 



An abstract syntax for if-statements, expression-statements, and assignment 
expressions (as may be found in languages such as C and Java) is specified in 
Table 1. We do not try to make a syntactic distinction between boolean and 
other expressions, since the types of variables in expressions usually depend on 
their declarations, making the syntax of well-typed expressions context-sensitive. 
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Table 1. Abstract syntax 



s € Stm ;:= if ( Exp) Stm \ Exp ; | . . . 
e G Exp Var = Exp | . . . 

X G Var 



When formulating dynamic semantics, we need not worry about what seman- 
tics is given to programs containing ill-typed expressions, assuming that such 
programs are filtered out by a preceding static semantics. 

The grammar in Table 1 is unambiguous, but in fact with grammars for 
abstract syntax, ambiguity does not give rise to any problems. For instance, 
a production such as Exp ::= Exp == Exp simply specifies that both the left 
and right sub-trees of the trees for this construct are of the same sort, namely 
Exp. Incidentally, some authors prefer to use ordinary variables, rather than 
sort names, as nonterminal symbols in abstract syntax grammars, writing for 
example e ::= ej == eg instead of Exp ::= Exp == Exp. 

\> Formal semantics aims at modelling the observable behaviour of complete 

programs. 

In the models used in formal semantics, low-level implementation-dependent de- 
tails are generally ignored, e.g. bounds on the size of numbers or arrays, limits 
on the depth of recursive procedure calls, or the way in which memory is allo- 
cated and freed. The actual binary representation of values is ignored too, and 
computed values are modelled as abstract mathematic entities. For instance, the 
values computed by our illustrative expressions e G Exp may be modelled as 
abstract values v G V , including the familiar mathematical integers n G Z and 
the boolean values tt,ff G B. 

As usual when giving a model, auxiliary entities may be introduced purely 
to facilitate the construction of the model. For dynamic semantics, the auxiliary 
entities typically include environments p G Env = Ide — >■ L, stores a G S = 
L — >■ F, and locations I G L. The auxiliary entities do not themselves have to 
correspond to actual components of implementations. 

Many frameworks require semantics to be specified not only for complete pro- 
grams, but also for all their parts (statements, declarations, expressions, etc.). 
The semantics of such parts are regarded as auxiliary entities too, since imple- 
mentations are not obliged to follow the compositional structure of the language. 
For our purposes here, however, we shall not bother to distinguish complete pro- 
grams from other syntactic constructs. 

t> We focus on frameworks of current interest. 

Our purpose here is not to give a comprehensive historical account of the devel- 
opment of the various frameworks for formal semantics, but rather to limit our 
attention to frameworks of current interest. 
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2.1 Operational Semantics 

Various frameworks for operational semantics of programming languages have 
been developed, starting from the early 1960’s [33]. Here, we consider Structural 
Operational Semantics and Natural Semantics (together with their recently- 
developed modular variants). Reduction Semantics, and the Abstract State Ma- 
chine approach. 



> Operational semantics models the computations of programs. 

A computation is usually regarded as a (perhaps infinite) sequence of steps be- 
tween states. An alternative approach is to represent (terminating) computations 
as derivation trees, where the steps occur as leaves but without explicit sequenc- 
ing. 



> The semantics of a program is determined by the set of possible computa- 
tions, modulo some equivalence relation. 

States in computations generally incorporate the abstract syntax of the entire 
program — or at least, the part of it that remains to be executed. Thus no two 
syntactically-distinct programs can ever have the same (non-empty) sets of pos- 
sible computations, even when their differences are obviously insignificant. To 
obtain a reasonable notion of semantic equivalence in operational semantics, 
some equivalence relation that ignores the syntactic components of states has to 
be introduced; a popular choice is bisimulation equivalence [35] . 



Structural Operational Semantics (SOS) was proposed by Plotkin in 1981 
[51]. The main aim was to provide a simple and direct method, allowing concise 
and comprehensible semantic descriptions based on simple mathematics. The 
basic ideas of SOS have since been presented (on a less ambitious scale) in 
various textbooks (e.g. [48]), and exploited in numerous papers on concurrency 
[34]; see also [2]. 

> Computations are modelled as sequences of (possibly labelled) transitions 

between states involving syntax, computed values, and auxiliary entities. 

The sequences may be finite or infinite. The states themselves are finite math- 
ematical entities, but in contrast to automata theory, the sets of states here are 
generally infinite. 

Characteristic for SOS is that as a computation proceeds, phrases of the 
program (i.e. branches of the abstract syntax tree) are gradually replaced by the 
values that they have computed. Thus in an initial state the program tree is 
purely syntactic, in a final state it has been replaced by its computed value, and 
in between, it is usually a mixture of syntax and computed values. It may also 
happen that phrases get replaced by different trees, possibly involving auxiliary 
constructs not present in the original syntax of the language being described. 
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Auxiliary components of states often include stores such as a G S = L ^ V 
and environments such as p G Env = Vor —1 L, where L is some set of locations 
(i.e. addresses in memory). Environments however may also be taken as an extra 
argument of the transition relation in a so-called relative transition system [51]; 
they can be avoided altogether by use of syntactic substitution.^ 

t> Transitions are specified by axioms and inference rules. 

In sequential languages, a step for a compound phrase depends on a step for 
a sub-phrase, whereas in concurrent languages, it may depend on synchronized 
steps for more than one phrase. Table 2 shows the axioms and inference rules 
for the constructs whose abstract syntax was specified in Table 1. 



Table 2. Structural operational semantics 



e G Exp ::=...] V 
s G Stm . . ■ | () 



pG s, 



pG e,(j — > e' , o' 
pG if (e)s,cr — > if (e')s,cr' 
p h if (It) s, cr — > s,o pGif(.ff)s,a — 



( 1 ) 

(2) 



\pG e, 



pG e, a 



pG x = e,a 



■ e ,a 



pGx = v,a — > v,a[v/l] a I — p{x) (3) 



Natural Semantics was developed by Kahn and his group at Sophia Antipolis 
in the mid-1980’s [29]. It is sometimes referred to as “big-step” SOS. It can 
be used together with the pure “small-step” SOS — in fact the big-step style is 
actually just a (very) special case of the small-step style, involving initial and 
final states but no intermediate states. Plotkin used the transitive closure of a 
small-step transition relation to specify that a small step of statement execution 
depended on an entire expression evaluation [51]. 



t> Terminating computations are modelled as evaluation relations between syn- 
tax and computed values, possibly involving auxiliary entities. 

One drawback of natural semantics is that nonterminating computations are 
generally ignored.^ On the other hand, it may be seen as an advantage that 

^ The actual definition of substitution is rather tedious, and usually left to the reader’s 
imagination. . . 

^ Nontermination can be modelled by use of infinitary logic [6,12]. 
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computed values do not need to be allowed as components of abstract syntax 
trees in natural semantics, in contrast to SOS. 

The usual style is to exhibit the environment as an extra argument to the 
evaluation relation, as illustrated in Table 3; the resemblance to sequents in 
Gentzen calculi for Natural Deduction led to the name of the framework. 



t> Evaluations are specified by axioms and inference rules. 

In sequential languages, evaluation of a compound phrase depends on the eval- 
uation of all the involved sub-phrases. However, the rules are not strictly induc- 
tive, in general: e.g. a (terminating) evaluation of a loop may depend on another 
evaluation for the same loop. The description of concurrent languages, or even 
of interleaved expression evaluation, is problematic in pure natural semantics, 
because of the lack of intermediate states. A compromise between small- and 
big-step semantics is evaluation to “committed form” [53]. 

The need to “thread” effects on stores explicitly through premises of rules 
when describing conventional imperative languages is a considerable disadvan- 
tage of Natural Semantics — so much so that when this framework was used for 
the Definition of Standard ML [36], a convention was introduced so that the 
store could actually be left implicit in most rules (the premises being written in 
the intended order of evaluation of sub-expressions). A similar convention was 
adopted regarding the propagation of exceptions. 



Table 3. Natural semantics 



e € Exp 
s G Stm 



p\- e, a — > tt, o' 
p\- s, a' — >■ a” 
p\- if (e) s, (7 — >■ a” 



p\- s, 



p\- e, a — > ff, a' 
p\- if (e) s, (T — y a 



(4) 



p h e, CT — y V, a' 



p\- e, a 
p\- x = e,a - 



v,a'[v/l\ 



if I = p{x) 



(5) 



Modular Operational Semantics was developed by the present author at 
the end of the 1990’s [44,46], with the aim of improving some of the pragmatic 
aspects of the conventional SOS and natural semantics frameworks — inspired by 
the improvements that can be obtained in denotational semantics by the use of 
monads, see Sect. 2.2. 
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> Modular SOS is a variant of SOS where states are restricted to syntax and 
computed values, and all auxiliary entities are incorporated in labels on tran- 
sitions. 

Labels in modular SOS may include all the auxiliary entities normally employed 
in the conventional SOS framework, for example environments, (pairs of) stores, 
and (sequences of) communication signals. The set of labels is generally infinite. 
It is straightforward to reduce a modular SOS to a conventional SOS, by moving 
the relevant components of the labels back to their usual places in the states. 



> Computations require adjacent labels to be composable. 

Composition of labels, written ; ag, is usually partial: when labels contain 
environments, they compose only when the two environments are the same; and 
when they contain pairs of stores, the second store in the first label has to be 
the same as the first store in the second label. The presence of communication 
signals, however, does not affect composability. 

In fact the set of labels always forms a category. Let the variable a range 
over all labels, but let l range only over identity labels. The objects of the label 
category may be regarded as the semantic components of states — which are 
clearly separated from the syntactic components in this framework, in contrast 
with all other operational frameworks. Notice in Table 4 how arbitrary labels 
a are propagated during the evaluation of sub-expressions, whereas labels on 
reduction steps are required to be identities i.. 

New components can be added to labels by applying label transformers, which 
form product categories. Not only do label transformers leave the rules well- 
formed (so that they never need reformulating when extending the described 
language), but also computations and bisimulation equivalence are preserved 
[43]. 



Table 4. Modular SOS 



e € Exp ::=...[ V 
s G Stm ::= . . . | () 




if (e)s 
if (,tt)s — s 



if (e')s 
±Uff)s 



0 



(6) 

(7) 




e 



(8) 



q: 



x = v 



V if 1 = i'.p{x), 



a = l\(j' = L.(j[v /I]] 



(9) 
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t> Similarly, Modular Natural Semantics requires all auxiliary entities to be 
incorporated in labels on evaluations. 

Apart from the usual differences between SOS and natural semantics, observe in 
Table 5 that composition of labels has to be used explicitly in modular natural 
semantics. This composition corresponds to the threading of the store through 
premises of rules in conventional natural semantics, as was illustrated in Table 3. 
In fact sequential composition is not the only possibility for combining labels: 
when the labels of a modular natural semantics are taken to be finite sequences, 
it is possible to describe interleaving in terms of shuffling labels. 



Table 5. Modular natural semantics 



e € Exp 
s G Stm 



tt 

0 



if (e)s 



0 



if <y = di ; 0C2 



ff 



if (e)s 



0 




if I = r.p(a:), 



a = ai \ b[a' 



b.a[v/l]] 




(10) 




( 11 ) 



Reduction Semantics was developed by Felleisen and his colleagues towards 
the end of the 1980’s [16]. 

> Computations are modelled as sequences of term rewriting steps (reduc- 
tions). 

Here, both computed values and auxiliary entities are represented as terms: there 
is little or no separation between syntactic and semantic entities. The sequence 
of rewriting steps in a computation may be infinite. 

> Reductions are restricted to occur in evaluation contexts, the general form 
of which is specified by a context-free grammar. 

The unique hole in each context is indicated by ‘[]’ in the grammar for the 
contexts STM and EXP in Table 6. Filling the hole of a context A by a tree 
b is written A[b]. Observe that the alternatives for contexts correspond to the 
inference rules for the same constructs in Table 2. Clearly, it is more concise to 
specify a grammar than a set of inference rules. Moreover, reduction semantics 
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has the advantage over SOS that a reduction step may replace the context (as 
well as its contents), which can exploited not only to deal with effects on storage, 
but also with control constructs such as call/cc. Reduction semantics has the 
advantage over natural semantics that it can cope with non-terminating com- 
putations, as well as with synchronization and interleaving [52]; but it does not 
appear to have significant advantages over SOS, apart from greater conciseness. 



Table 6. Reduction semantics 



e e 


Exp 




1 true 1 false j L j V 


s e 


Stm 


:= . . . 


!{} 


S e 


STM 


:=[] 


±f{EXP)Stm 1 ... 


E £ 


EXP 


:=[] 


L=EXP 1 ... 



if(true)s-^s if (false) s —>■ {} 



5[s], cr — >• ^[s'], (T if s — >• s' 
S[l = v],a > cr[t)//] 




(14) 



Abstract State Machines (ASMs) , previously called “evolving algebras” [20] , 
is a framework proposed by Gurevich in the late 1980’s. 

> Computations are modelled as sequences of parallel sets of assignments to 
values of particular functions on particular arguments. 

The sequences may be finite or infinite. Dynamic function values remain stable 
when not updated; functions declared to be static never get updated after their 
initial definitions. The values of all the functions determine the state of the 
computation. 



t> States include control-flow graphs representing the entire program. 

In the fragment shown in Table 7, the functions fst, nxt represent normal control 
flow between phrases. However, flow of control need not follow the structure of 
the program at all: in principle, the pointer task, normally indicating the next 
part of the program to be executed, can be set arbitrarily. The control-flow graph 
itself is static, but computed values can be associated with nodes by a separate 
dynamic function, such as val in Table 7. Scopes of bindings are represented 
indirectly, by explicit stacking of values, rather than by using environments or 
syntactic substitution. 
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Table 7. Abstract state machines 



task : Phrase 

fst, nxt : Phrase — >■ Phrase 

val : Exp — >■ V 

let s' = if (e)s in (15) 

fst(s') = fst{e), nxt{e) = s' , nxt{s) = nxt(s') 

if task is if (e)s then (16) 

if val{e) then task := fst{s) 

else task ~ nxt(task) 

let e' = (x = e) in (17) 

fst(e') = fst{e), nxt{e) = e' 

if task is (x = e) then (18) 

loc{x) := val(e), 
valitask) ;= val{e), 
task := nxt {task) 



Other Operational Frameworks 

t> Various other operational frameworks have been developed. 

These include translation to code for the SECD abstract machine [31] and the 
VDL abstract machine [61], the SMoLCS framework [7], and the EOS framework 
[13]. 

2.2 Denotational Semantics 

Apart from the original Scott-Strachey style of denotational semantics, we con- 
sider here also VDM, Monadic Semantics, and Predicate Transformers. 

> Denotational Semantics models each part of a program as its denotation, 
representing its contribution to the overall behaviour of the enclosing pro- 
gram. 

Denotations are typically higher-order functions between complete partial orders 
(epos) [19]. The semantics of a complete program is its observable behaviour, 
which is obtained from its denotation. 

> Semantic functions that map phrases to their denotations are defined induc- 
tively by sets of semantic equations, ensuring compositionality. 

Such inductive definitions correspond to so-called initial algebra semantics [18]. 
The semantics of loops and recursion usually involves the explicit use of fixed- 
point operators, although some authors prefer to specify these as equations whose 
(least) solution is to be found. 
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Scott-Strachey Semantics is the original style of denotational semantics, 
developed by Scott and Strachey at the end of the 1960’s [40,48,54,56,57]. 

t> Domains of denotations and auxiliary entities are defined by domain equa- 
tions. 

The domains are usually w-complete partial orders (epos); only continuous func- 
tions between domains are considered. Domain equations always have “least” so- 
lutions (up to isomorphism), e.g. D = N +\D ^ D] defines a domain D including 
both the natural numbers and all continuous functions on D. The elements of 
domains are specified in typed A-notation. 

> Typically, denotations are functions of environments, continuations, and 
stores. 

Many standard techniques for representing programming concepts as pure math- 
ematical functions have been established. For instance, sequencing may be rep- 
resented either by composition of strict functions, or by use of continuations; 
the latter are illustrated in Table 8. The denotational description of nondeter- 
minism, concurrency, and interleaving requires the use of power domains (and a 
significant amount of extra notation). 



Table 8. Scott-Strachey semantics 



p G Env = Var — >■ V 
a€ S =L^ V 

6€ C =S^A 

K =V ^ C 
S : Stra Env C ^ C 

£ : Exp — >■ Env K ^ C 

5|if(e)s] = \p.\e.£[e\p{\v.v\B 5|s]p6»,6») (19) 

f[a: = e] = \p.\K.£\e\p{\v.\<j.n{v){a[v / p{x)\L])) (20) 



VDM Semantics is a notational variant of denotational semantics, developed 
by Bjprner and C. B. Jones in the mid-1970’s [9] for use in software development. 

> The meta-notation Meta-IV used in VDM provides extra generality regard- 
ing abstract syntax. 

Lists, sets, and maps may be used as components of abstract syntax trees. This 
allows some semantic properties, such as the insignificance of the order of dec- 
larations in certain languages, to be made evident in the abstract syntax;. 
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> It also ensures propagation of effects and exceptions. 

Meta-IV provides notation for sequencing effects on stores, the use of which is 
illustrated in Table 9, and for exception-handling. 



Table 9. VDM semantics 



M-.Stm^ ENV S^S 
M: Exp ^ ENV ^ S^S X V 




A4[mk-If(e, s)](p) = def v : At[e](p); 

if V then M.[s]{p) else Is 


(21) 


M[mk-Assign{x , e)](p) = def 1 : p{x)\ 

def V : M[e2]{py, 
assign)/, ti); return(ti) 


(22) 



Monadic Semantics was developed by Moggi at the end of the 1980’s [37,38], 
based on category-theoretic concepts. 

t> Denotations in Monadic Semantics are elements of monads, and their com- 
position is expressed independently of the domains used to construct the 
monads. 

Intuitively, a monad corresponds to a particular notion of computation. Vari- 
ous notations for monadic composition are available. In the one whose use is 
illustrated in Table 10, ‘let v = ci in C 2 ' expresses that the computation cj 
is performed first; the computed value is then referred to as v in the compu- 
tation C 2 - In so-called exception monads, raising an exception in ci may cause 
C 2 to be skipped; various other monads define composition in different ways. 
The use of the composition notation depends only on knowing the type of value 
computed by Cj , not on the structure of the domain of computations in any par- 
ticular monad. The notation ‘[u]’ expresses the trivial computation that merely 
returns the value v. Comparing Tables 9 and 10, the closeness of the monadic 
notation to that provided a decade earlier by Meta-IV is quite striking. 

t> Monad transformers construct monads incrementally, and lift the associated 
functions. 

A monad transformer adds a new aspect of computation to a given monad. 
The order of applying the transformers can be critical — in particular, the trans- 
formers that provides continuations does not commute with other transformers. 
Moreover, not all functions can be lifted uniformly through monad transformers. 

Moggi has subsequently developed a more general (and rather less category- 
theoretic) framework based on translation between meta-languages [39]. 
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Table 10. Monadic semantics 



S : Stm^ T{) 




S : Exp ^ r( V) 




5|if (e)s] = let t) = f|e] in 


(23) 


case v\B of {tt ^ 5|s] j ff ^ [()]) 




£\x = e] = let Z = lookup{x) in 


(24) 



let V = Slej in 

let 0 = assign{l, v) in [ri] 



Predicate Transformer Semantics was proposed by Dijkstra in the mid- 
1970’s [15]. It is often regarded as axiomatic, since it involves assertions about 
the values of variables before and after executing statements. However, it is more 
properly classified as denotational. 

t> The denotation of a phrase is a predicate transformer that returns the weak- 
est condition which ensures termination of the phrase with the argument 
condition holding. 

Predicate transformers are required to have properties corresponding to con- 
tinuity of functions on Scott-domains. The description of assignment involves 
substitution in formulae. Expression evaluation is assumed to be free of side- 
effects, errors, and non-termination, so that boolean expressions may be used as 
formulae, and expressions substituted syntactically for variables. In the illustra- 
tions given below and in Sect. 2.3, we treat only assignment statements of the 
form X = e;, and assume that assignment expressions cannot occur elsewhere. 



Table 11. Predicate transformer semantics 
wp : Stm X Pred — >■ Pred 

wp(if(e)s, Q) <=> (e => wp(s, Q)) A (-■ e Q) (25) 

wp(x = e;, Q) 4^ Q[e/x] (26) 



Other Denotational Frameworks include Naive Denotational Semantics 
[10], partially-additive semantics [32], use of metric spaces [4], and Extensible 
Denotational Semantics [11]. Further variants of denotational semantics involve 
natural transformations between categories of stores [49] , Linear Logic and games 




180 



P.D. Mosses 



2.3 Axiomatic Semantics 

Here we consider both Hoare Logic and Algebraic Semantics. 

t> Axiomatic semantics restricts the potential models by asserting properties. 

As usual with axiomatic specifications, it may be unclear whether sufficiently 
many properties have been given (if not, there may be more than one model), or 
whether an inconsistent set of properties has been given (then there are no mod- 
els at all, cf. [5]). As with predicate transformers, boolean expressions are used 
as formulae, and the semantics of assignment statements involves substitution 
of expressions for variables, so expressions cannot have side-effects. 



Hoare Logic was developed in the late 1960’s [26]. 

> Partial correctness assertions are specified by axioms and inference 

rules. 

The partial correctness assertion requires that if P holds and the sub- 

sequent execution of the statement s terminates, then R holds. A general rule, 
applicable to all statements, is included in Table 12 to allow strengthening of 
pre-conditions and weakening of post-conditions. 



Table 12. Hoare logic 



{P A e){s}7J (P A e => 7?) 
P{if(.e)s}R 



P[e/x\{x = e-,}P 



P' ^ P P{s}R R^ R' 
P'{s}R' 



(27) 

(28) 



Algebraic Semantics for programming languages was developed by Hoare and 
his colleagues at Oxford in the 1990’s [27]. 

> Equations and inclusions between phrase terms characterize the relationship 
between their interpretations. 

It appears that this approach is applicable only to languages that have a partic- 
ularly expressive syntax and clean semantics. 



Other Axiomatic Frameworks include Dynamic Logic [23]. 
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Table 13. Algebraic semantics 



if (e)P = (e — >■ P [] -I e ^ sfcjp) (29) 

e P = e^; P (30) 



2.4 Complementary Semantics 

t> Particular semantic frameworks may have advantages for different uses. 

It has been proposed [27,28,54] that one should give not just one but several 
complete descriptions of the same language, using different kinds of frameworks. 

> The different descriptions of a language should be consistent. 

It is well known that it is difficult to prove consistency between semantic de- 
scriptions in different frameworks. To derive one description from another, for 
example by use of abstract interpretation [12], may be more feasible, and help 
to ensure consistency. 

2.5 Hybrid Semantics 

t> A hybrid approach to semantics involves more than one framework in the 
same description. 

An analogous example of a hybrid approach in descriptions of syntax is the use 
of regular grammars to describe lexical symbols, and of context-free grammars 
to describe phrase structure with lexical symbols as terminal symbols. 

t> The various semantic frameworks may have advantages for different levels of 
complete semantic descriptions. 

The separation of semantics into static and dynamic phases encourages a hybrid 
approach to complete semantic descriptions; below, we consider approaches that 
involve hybrid descriptions also within dynamic semantics. 



Action Semantics was developed by the present author, in collaboration with 
Watt, in the second half of the 1980’s [41,47,59]. 

t> Action Semantics is a hybrid of denotational and operational semantics. 

As in denotational semantics, inductively-defined semantic functions map 
phrases to their denotations, only here, the denotations are so-called actions; 
the notation for actions is itself defined operationally [41,45]. 
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t> Action semantics avoids the use of higher-order functions expressed in 
lambda-notation. 

The universe of pure mathematical functions is so distant from that of (most) 
programming languages that the representation of programming concepts in it 
is often excessively complex. The foundations of reflexive Scott-domains and 
higher-order functions are unfamiliar and inaccessible to many programmers 
(although the idea of functions that take other functions as arguments, and per- 
haps also return functions as results, is not difficult in itself). The use of pure 
lambda-notation has some pragmatic drawbacks, especially concerning modu- 
larity; the monadic style of denotational semantics was developed (partly) to 
circumvent these. 

t> Action semantics provides a rich action notation with a direct operational 
interpretation. 

The universe of actions involves not only control and data flow, but also scopes 
of bindings, effects on storage, and interactive processes, allowing a simple and 
direct representation of many programming concepts. The foundations of ac- 
tion notation involve SOS and algebraic specifications, which are both generally 
regarded as more accessible than domain theory. 



Table 14. Action semantics 



execute : Stm — >• action\gwing{)] 
evaluate : Exp — >■ action[giving a value] 

execute[i±(.e)s^ = evaluatele] then (31) 

( given true then exeeute\s\ otherwise skip ) 

evaluate\x = e\ = give the variable bound to x and evaluatele} (32) 

then ( assign and give the valuers ) 



Other Hybrid Frameworks include Modular Denotational Semantics [17], 
Modular Monadic Action Semantics [58], Type-Theoretic Interpretation [24], 
and translation between meta-languages [39]. As mentioned earlier, various op- 
erational frameworks such as VDL may be considered as hybrids. 

3 Potential and Actual Uses 

We have seen that many different semantic frameworks have been developed. Let 
us now consider the main potential uses of formal semantic descriptions, and list 
some of the actual uses.^ 



® The author would be grateful for reports of further cases of practical use. 
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3.1 Potential Uses of Semantic Descriptions 

t> Formal semantic descriptions may be used by language designers to record 
their decisions. 

Formal grammars are useful for recording proposals and decisions concerning 
(concrete and abstract) syntax during the language design process; semantic 
descriptions could be just as useful for recording the intended semantics of the 
constructs concerned. In cases where the language designers do not formulate a 
proper semantic description, their familiarity with semantic concepts may still 
be beneficial to the design process, of course. 

t> Such descriptions may also be used in the documentation of a completed 
language design. 

A reference manual or standards document for a programming language should 
provide complete and unambiguous descriptions of both the syntax and the 
semantics of the language. Unofficial semantic descriptions contributed by “out- 
siders” , however, may often be of little real use (except for demonstrating that 
particular frameworks can be used to describe particular languages) and will be 
ignored here.^ 

t> Formal semantic descriptions may be used to derive implementations. 

Ideally, it would be possible to generate an efficient compiler or interpreter au- 
tomatically from a semantic description, — just as scanners and parsers can be 
generated from grammars. Even generation of inefficient implementations may 
be adequate for rapid prototyping purposes, and for languages where efficiency is 
of no concern. Formal semantic descriptions may also be the basis for systematic 
(manual) development of implementations. 

t> They may be used in connection with program verification or development. 

One of the primary advantages of formal semantic descriptions is that they 
provide a basis for sound reasoning about program behaviour and equivalence. 



3.2 Actual Uses of Semantic Descriptions 
Operational Semantics: 

SOS was used during the design of Facile (a higher-order, concurrent language). 
The SMoLCS variant of SOS was used to describe full Ada in an official 
project. (SOS has also been much used to describe process calculi, including 
LOTOS, but here, let us restrict our attention to descriptions of languages 
that are normally used for programming rather than specification.) 

^ The questions that they often raise about details of language design may be prompted 
by any close and systematic study. 
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Natural Semantics was used during the design of Standard ML (SML), and to 
give an official definition of the language. The ML Tool-Kit implementation 
of SML was derived systematically from the official definition. 

Reduction Semantics was used during the design of Concurrent ML (CML). 
However, the formal semantic description of CML has apparently not been 
incorporated in the CML reference manual — nor is there even a link to it 
from the CML home page. 

ASM was adopted by ISO for use in the Prolog standard, and by ITU for use 
in the standard for SDL-2000 (the description of the latter being however 
in quite a different style from that previously used in ASM specifications). 
Also, a recent book including ASM specifications of Java and the JVM de- 
serves mention as “the most comprehensive and consistent formal account of 
Java and the JVM, to date” (although it does not appear to have received 
any endorsement from the language developers). An ASM specification of a 
language for Universal Plug and Play (UPnP) is apparently being used by 
developers at Microsoft. ASM descriptions of Prolog and Occam have been 
used as a basis for program verification and the derivation of implementa- 
tions. 



Denotational Semantics: 

Scott-Strachey semantics was used during the design of Ada, and the result- 
ing description (of sequential Ada only) was included as part of the official 
language documents. The same style of semantics was used by the designers 
of the functional programming language Scheme, and subsequently incorpo- 
rated in the Scheme reference manual. 

VDM was used in the CCITT standard for the telecommunication language 
CHILL, and in the ISO standards for SDL-88, SDL-92, and SDL-96. A suc- 
cessful Ada compiler was derived systematically from a VDM description of 
the full language. 

Monadic semantics appears to be currently lacking an example of its use in 
connection with a practical programming language. 



Axiomatic Semantics: 

Hoare Logic was used during the design of Pascal, and the resulting descrip- 
tion as the basis for program verification. 

Algebraic Semantics influenced the design of Occam, and the resulting alge- 
braic semantics of Occam itself may be regarded as part of the reference 
material for the language. Algebraic semantics has also been used as the 
basis for the development of a correct compiler for Occam. 



Hybrid Semantics: 

Action Semantics was adopted to describe the language ANDF [22] (a lan- 
guage intended for use in software package distribution). 
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Compared to the amount of effort that has been devoted to the development of 
various semantic frameworks over more than three decades, and all the potential 
uses listed above, the list of actual uses may be considered as relatively disap- 
pointing. Why has there not been far greater use of formal semantics in practice? 
Some — or perhaps even all — of the factors listed in the following section may be 
relevant. 



4 Hindrances to Greater Use 



t> Many frameworks for semantics are not particularly user-friendly. 

In some frameworks, the familiar programming concepts underlying a described 
language (such as flow of control and scopes of bindings) are not indicated by 
fixed symbols, but rather get encoded in patterns of use of general notation. 
For instance, order of evaluation may be specified by patterns of transitions in 
inference rules in SOS or Natural Semantics, and by use of patterns of lambda- 
notation in Denotational Semantics. This reduces comprehensibility (at least 
until the relevant patterns have been learned). A related potential hindrance is 
when the details of mathematical foundations are reflected directly in semantic 
descriptions, since those foundations may seem inaccessible to many potential 
users [55]. 

Practical use of formal semantics involves descriptions of major program- 
ming languages. Few frameworks scale up smoothly from the tidy illustrative 
languages described in text-books and papers to languages such as C and Java — 
even Standard ML, a clean language designed by theoreticians, turned out to be 
a considerable challenge to describe accurately in Natural Semantics. Tool sup- 
port could alleviate the problems of writing, checking, and navigating in large- 
scale descriptions, but mature tools are totally lacking for most frameworks, in 
marked contrast to the sophisticated programming environments available to 
programmers [25]. 



t> Much effort is required to develop a complete semantic description, but the 
potential benefits are somewhat intangible. 

For theoreticians, there is generally little academic reward for producing a se- 
mantic description of a full programming language (unless it is so interesting that 
it can be published as a book). Merely overcoming pragmatic problems in ap- 
plications of semantics is not of much theoretical interest. Practitioners involved 
with designing and implementing a programming language have to weigh the 
effort of formulating a formal semantics against how much practical advantage 
it gives. In any case, the number of potential users for any particular semantic 
description is generally very small. 



> In contrast, formal syntax has become quite popular. 
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One reason for the popularity of formal grammars may be that BNF — at least 
when extended with notation for iteration and optional phrases — is exceptionally 
user-friendly. The major relevant concepts (alternatives, sequencing, and itera- 
tion) are all expressed directly, and the notational variation concerning iteration, 
although irritating, does not impede reading and understanding grammars. BNF 
scales up smoothly to descriptions of larger languages. Moreover, practical use 
of formal syntax is strongly supported by tools, both for prototyping grammars 
(e.g., to check that a grammar is actually LALR(l)) and for generating useful 
parsers. 

\> Formal semantic descriptions should aim for the practicality of BNF. . . 

Denotational semantics espoused the idea of extending BNF to semantics, but 
the good pragmatic aspects of BNF have been sadly lacking in denotational 
descriptions (at least during the 1970’s and 1980’s, before the development of 
the monadic approach); most of the other frameworks surveyed in Sect. 2 suffer 
from similar problems with pragmatic aspects, especially regarding lack of tool 
support. 

5 Conclusion 

\> A large number of semantic frameworks have been provided during the past 
three decades. 

We have classified them mainly as operational, denotational, and axiomatic. 
To give complementary semantic descriptions of the same language in different 
frameworks (and prove them consistent) appears to be much too demanding, at 
least for the average semanticist. It seems preferable to exploit the best features 
of the various frameworks synergistically, in different parts of a single hybrid 
description. 

\> There are plenty of potential uses for formal semantic descriptions, but dis- 
appointingly few actual practical applications of real significance (so far) . 

Language designers seldom use formal semantic descriptions at all during the 
design process [60] . In only a few cases has a formal semantics of a language has 
been provided for reference purposes, and implementors have referred to it for 
clarification. 

\> The main hindrances to greater use of formal semantics appear to be lack of 
user-friendliness, and lack of tool support. 

Semantic descriptions in many frameworks have poor pragmatic aspects, for 
instance concerning modularity and the smoothness of scaling up to descriptions 
of larger languages. Quality tools are badly needed to assist the writing, checking, 
and reading of semantic descriptions. Meta-systems such as the ASF-I-SDF Meta- 
Environment and Maude may support the development of such tools for some 
semantic frameworks. 
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t> Development of a user-friendly semantic framework allowing generation of 
efficient compilers should encourage practical use. 

Semantics-directed compiler generation was a popular topic for PhD theses in 
the 1980’s and the first half of the 1990’s. Despite the construction of some 
promising prototype systems, no tools for producing efficient compilers directly 
from semantic descriptions appear to be currently available.^ To have such tools 
would not only provide a real incentive for writing semantic descriptions, they 
would also allow the empirical testing of whether the semantics really does define 
the intended language. 



> The ASM approach is a good candidate for such a framework. 

As may be seen from the ASM web pages at http://www.eecs.umich.edu/ 
gasm, the ASM approach has a large and energetic following, and has already 
made a considerable impact regarding practical applications — although compiler 
generation does not yet appear to be one of its strengths. 

> Action Semantics also looks promising. 

Action semantics was designed with user-friendliness as first priority; it was cho- 
sen for use in the description of ANDF because of its good pragmatic qualities 
[21]. Substantial experience with prototype systems for compiler and interpreter 
generation based on action semantics has already been obtained. A new, signifi- 
cantly simplified version of action semantics is currently about to be released — 
simple enough to be taught at undergraduate level. Not many people are working 
on action semantics at present. Readers who might be interested in helping to 
produce useful tools for action semantics, especially compiler generators, are cor- 
dially invited to take a closer look at the framework from the materials available 
via the home page at http://www.brics.dk/Projects/AS, and to contact the 
author if wanting to help. 



Acknowledgements. Thanks to Yuri Gurevich, Jan Heering, Cliff Jones, Paul 
Klint, John Reynolds, Dana Scott, and several participants at PSI’Ol, for crit- 
ical comments on the preliminary version of this paper, “What Use Is Formal 
Semantics?”; and to Bartek Klin for suggesting improvements to a draft of the 
revised version. The responsibility for remaining infelicities in the contents or 
presentation is entirely the author’s. Thanks also to the organizers of PSFOl for 
the invitation to speak on this topic, and to the editors of these Proceedings 
for their patience. The author gratefully acknowledges the support of BRIGS 
(Basic Research in Computer Science, funded by the Danish National Research 
Foundation). 

® The RML system [50] is however able to produce efficient interpreters from (a special 
form of) natural semantics. 




188 



P.D. Mosses 



References 

1. S. Abramsky and G. McCusker. Linearity, sharing, and state: A fully abstract 
game semantics for Idealized Algol with active expressions (extended abstract). 
In Proc. 1996 Workshop on Linear Logic, volume 3 of Electronic Notes in TCS. 
Elsevier, 1996. 

2. L. Aceto, W. Fokkink, and C. Verhoef. Structural operational semantics. In J. A. 
Bergstra, A. Ponse, and S. A. Smolka, editors. Handbook of Process Algebra, chap- 
ter 3, pages 197-291. Elsevier Science, 2001. 

3. C. Alexander. A Timeless Way of Building. Oxford University Press, 1979. 

4. P. America, J. de Bakker, J. N. Kok, and J. J. M. M. Rutten. Denotational 
semantics of a parallel object-oriented language. Information and Computation, 
83(2):152-206, 1989. 

5. E. A. Ashcroft, M. Clint, and C. A. R. Hoare. Remarks on ‘Program proving: 
Jumps and functions, by M. Clint and C. A. R. Hoare’. Acta Inf., 6:317-318, 1976. 

6. E. Astesiano. Inductive and operational semantics. In E. J. Neuhold and M. Paul, 
editors. Formal Description of Programming Concepts, IFIP State-of-the-Art Re- 
port, pages 51-136. Springer- Verlag, 1991. 

7. E. Astesiano and G. Reggio. SMoLCS driven concurrent calculi. In TAPSOFT’87, 
Proc. Int. Joint Conf. on Theory and Practice of Software Development, Pisa, 
volume 249 of LNCS. Springer- Verlag, 1987. 

8. J. A. Bergstra, J. Heering, and P. Klint, editors. Algebraic Specification. Frontier 
Series. ACM Press, 1989. 

9. D. Bjprner and C. B. Jones. Formal Specification and Software Development. 
Prentice-Hall, 1982. 

10. A. Blikle and A. Tarlecki. Naive denotational semantics. In Information Processing 
83, Proc. IFIP Congress 83. North-Holland, 1983. 

11. R. Cartwright and M. Felleisen. Extensible denotational semantics specifications. 
In TACS’94, Proc. Symp. on Theoretical Aspects of Computer Software, Sendai, 
Japan, volume 789 of LNCS, pages 244-272. Springer- Verlag, 1994. 

12. P. Cousot and R. Cousot. Inductive definitions, semantics and abstract interpre- 
tation. In POPL’92, Proc. 19th ACM SIGPLAN-SIGACT Symp. on Principles of 
Programming Languages, Albuquerque, New Mexico, pages 84-94, 1992. 

13. P. Degano and C. Priami. Enhanced operational semantics. ACM Computing 
Surveys, 28(2):352-354, June 1996. 

14. A. van Deursen, J. Heering, and P. Klint, editors. Language Prototyping, volume 5 
of AMAST Series in Computing. World Scientific, 1996. 

15. E. W. Dijkstra. Guarded commands, non-determinacy, and formal derivations of 
programs. Commun. ACM, 18:453-457, 1975. 

16. M. Felleisen and D. P. Friedman. Control operators, the SECD machine, and the 
A-calculus. In Formal Description of Programming Concepts III, Proc. IFIP TC2 
Working Conference, Gl. Avemces, 1986, pages 193-217. North-Holland, 1987. 

17. J. A. Goguen and K. Parsaye-Ghomi. Algebraic denotational semantics using 
parameterized abstract modules. In J. Diaz and I. Ramos, editors, Proc. Int. 
Coll, on Formalization of Programming Concepts, Pehiscola, number 107 in LNCS. 
Springer- Verlag, 1981. 

18. J. A. Goguen, J. W. Thatcher, E. G. Wagner, and J. B. Wright. Initial algebra 
semantics and continuous algebras. J. ACM, 24:68-95, 1977. 

19. C. A. Gunter and D. S. Scott. Semantic domains. In J. van Leeuwen, A. Meyer, 
M. Nivat, M. Paterson, and D. Perrin, editors, Handbook of Theoretical Computer 
Science, volume B, chapter 12. Elsevier Science Publishers, Amsterdam; and MIT 
Press, 1990. 




The Varieties of Programming Language Semantics 189 



20. Y. Gurevich. Evolving algebras 1993: Lipari guide. In E. Borger, editor, Specifica- 
tion and Validation Methods. Oxford University Press, 1995. 

21. B. S. Hansen and J. Bundgaard. The role of the ANDF formal specihcation. 
Technical Report 202104/RPT/5, issue 2, DDC International A/S, Lundtoftevej 
1C, DK-2800 Lyngby, Denmark, 1992. 

22. B. S. Hansen and J. U. Toft. The formal specification of ANDF, an application of 
action semantics. In [42], pages 34-42, 1994. 

23. D. Harel. Dynamic logic. In Handbook of Philosophical Logic, volume II. D. Reidel 
Publishing Company, 1984. 

24. R. Harper and C. Stone. A type-theoretic interpretation of Standard ML. In 
G. Plotkin, C. Stirling, and M. Tofte, editors, Robin Milner Festschrifift. MIT Press, 
1998. 

25. J. Heering and P. Klint. Semantics of programming languages: A tool-oriented 
approach. ACM SIGPLAN Notices, Mar. 2000. 

26. C. A. R. Hoare. An axiomatic basis for computer programming. Commun. ACM, 
12:576-580, 1969. 

27. C. A. R. Hoare and H. Jifeng. Unifying Theories of Programming. Prentice-Hall, 
1998. 

28. C. A. R. Hoare and P. E. Lauer. Consistent and complementary formal theories 
of the semantics of programming languages. Act Inf., 3:135-153, 1974. 

29. G. Kahn. Natural semantics. In STACS’87, Proc. Symp. on Theoretical Aspects 
of Computer Science, volume 247 of LNCS, pages 22-39. Springer- Verlag, 1987. 

30. U. Hastens, P. Pfahler, and M. Jung. The eli system. In CC’98, Proceedings 7th 
International Conference on Compiler Construction, volume 1383 of LNCS, pages 
294-297. Springer- Verlag, 1998. 

31. P. J. Landin. A formal description of Algol60. In Formal Language Description Lan- 
guages for Computer Programming, Proc. IFIP TC2 Working Conference, 1964, 
pages 266-294. IFIP, North-Holland, 1966. 

32. E. G. Manes and M. A. Arbib. Algebraic Approaches to Program Semantics. 
Springer- Verlag, 1986. 

33. J. McCarthy. Towards a mathematical science of computation. In Information 
Processing 62, Proc. IFIP Congress 62, pages 21-28. North-Holland, 1962. 

34. R. Milner. Communication and Concurrency. Prentice-Hall, 1989. 

35. R. Milner. Operational and algebraic semantics of concurrent processes. In J. van 
Leeuwen, A. Meyer, M. Nivat, M. Paterson, and D. Perrin, editors. Handbook of 
Theoretical Computer Science, volume B, chapter 19. Elsevier Science Publishers, 
Amsterdam; and MIT Press, 1990. 

36. R. Milner, M. Tofte, and R. Harper. The Definition of Standard ML. The MIT 
Press, 1997. 

37. E. Moggi. An abstract view of programming languages. Technical Report ECS- 
LFCS-90-113, Computer Science Dept., University of Edinburgh, 1990. 

38. E. Moggi. Notions of computation and monads. Information and Computation, 
93:55-92, 1991. 

39. E. Moggi. Metalanguages and applications. In Semantics and Logics of Computa- 
tion, Publications of the Newton Institute. CUP, 1997. 

40. P. D. Mosses. Denotational semantics. In Handbook of Theoretical Computer 
Science, volume B, chapter 11. Elsevier Science Publishers, Amsterdam; and MIT 
Press, 1990. 

41. P. D. Mosses. Action Semantics. Number 26 in Cambridge Tracts in Theoretical 
Computer Science. Cambridge University Press, 1992. 




190 



P.D. Mosses 



42. P. D. Mosses, editor. AS’94, Proc. 1st Inti. Workshop on Action Semantics, Edin- 
burgh, number NS-94-1 in Notes Series. BRIGS, Dept, of Computer Science, Univ. 
of Aarhus, 1994. http : //www.brics . dk/NS/94/l/BRICS-NS-94-l/. 

43. P. D. Mosses. Foundations of modular SOS. Research Series RS-99-54, BRIGS, 
Dept, of Computer Science, Univ. of Aarhus, 1999. 
http://www.brics.dk/RS/99/54; full version of [44]. 

44. P. D. Mosses. Foundations of Modular SOS (extended abstract). In MFCS ’99, 
volume 1672 of LNCS, pages 70-80. Springer- Verlag, 1999. Full version available 
at http: //www.brics . dk/RS/99/54/. 

45. P. D. Mosses. A modular SOS for Action Notation (extended abstract). In AS’99, 
number NS-99-3 in Notes Series, pages 131-142, BRIGS, Dept, of Computer Sci- 
ence, Univ. of Aarhus, 1999. Full version available at 

http: //www.brics . dk/RS/99/56/. 

46. P. D. Mosses. A modular SOS for ML concurrency primitives. Research Series 
RS-99-57, BRIGS, Dept, of Computer Science, Univ. of Aarhus, 1999. 

http: //www.brics . dk/RS/99/57/. 

47. P. D. Mosses and D. A. Watt. The use of action semantics. In Formal Description 
of Programming Concepts III, Proc. IFIP TC2 Working Conference, Cl. Avernres, 
1986, pages 135-166. North- Holland, 1987. 

48. H. R. Nielson and F. Nielson. Semantics with Applications: A Formal Introduction. 
Wiley, Chichester, UK, 1992. 

49. F. J. Oles. A Category-Theoretic Approach to the Semantics of Programming Lan- 
guages. PhD thesis, Syracuse University, 1982. 

50. M. Pettersson. Compiling Natural Semanties, volume 1549 of LNCS. Springer- 
Verlag, 1999. 

51. G. D. Plotkin. A structural approach to operational semantics. Lecture Notes 
DAIMI FN-19, Dept, of Computer Science, Univ. of Aarhus, 1981. 

52. J. H. Reppy. CML: A higher-order concurrent language. In Proc. SIGPLAN’91, 
Conf. on Prog. Lang. Design and ImpL, pages 293-305. ACM, 1991. 

53. J. R. X. Ross. An Evaluation Based Approach to Process Calculi. PhD thesis. 
University of Cambridge, 1999. 

54. D. A. Schmidt. Denotational Semantics: A Methodology for Language Develop- 
ment. Allyn & Bacon, 1986. 

55. D. A. Schmidt. On the need for a popular formal semantics. ACM SICPLAN 
Notices, 32(1), 1997. 

56. D. S. Scott and C. Strachey. Toward a mathematical semantics for computer 
languages. In Proc. Symp. on Computers and Automata, volume 21 of Microwave 
Research Institute Symposia Series. Polytechnic Institute of Brooklyn, 1971. 

57. R. D. Tennent. The denotational semantics of programming languages. Commun. 
ACM, 19:437-453, 1976. 

58. K. Wansbrough and J. Hamer. A modular monadic action semantics. In Conference 
on Domain- Specific Languages, pages 157-170. The USENIX Association, 1997. 

59. D. A. Watt. Programming Language Syntax and Semanties. Prentice-Hall, 1991. 

60. D. A. Watt. Why don’t programming language designers use formal methods? In 
R. Barros, editor, Anais XXIII Semindrio Integrado de Software e Hardware, pages 
1-16, UFPE, Recife, Brazil, 1996. 

61. P. Wegner. The Vienna definition language. ACM Comput. Surv., 4:5-63, 1972. 




Binding-Time Analysis for Polymorphic Types 



Rogardt Heldal and John Hughes 

Chalmers University of Technology, S-41296 Goteborg 
heldalOcs . chalmers . se, www. cs . chalmers/~heldal. 



Abstract. Offline partial evaluators specialise programs with annota- 
tions which distinguish specialisation- time (or static) computations from 
run-time ones. These annotations are generated by a binding-time anal- 
yser, via type inference in a suitable type-system. Henglein and Mossin 
developed a type system which allows polymorphism in binding-times, so 
that the same code can be specialised with different computations being 
static at different uses. We extend their work to permit polymorphism 
in types as well. This is particularly important for separately compiled 
libraries. 

Following Henglein and Mossin, binding-times are passed as parameters 
during specialisation, but types are not. Instead, we pass coercion func- 
tions when necessary, which makes specialisation less “interpretive” than 
it would otherwise be. We keep track of the coercions needed by assigning 
qualified types to polymorphic functions. 

We also consider hand-annotations to provide limited user control over 
the binding-time analysis, which our prototype implementation showed 
to be necessary. 



1 Introduction 

Partial evaluation is by now a well-established technique for specialising pro- 
grams im. and practical tools have been implemented for a variety of program- 
ming languages PI1H8I5I . Our interest is in partial evaluation of modern typed 
functional languages, such as ML m or Haskell m- One of the key features of 
these languages is polymorphic typing [T^, yet to date the impact of polymor- 
phism on partial evaluation has not been studied. In this paper we explain how 
to extend an offline partial evaluator to handle a polymorphic language. 

1.1 Background: Polymorphism 

A polymorphic function is a function which may be applied to many different 
types of argument. In ML and Haskell, the types of such functions are expressed 
using a “forall” quantifier: for example, the well-known map function, which 
applies a function to every element of a list, has the type 

map :: Voi, 02.(01 — >■ 02) — t [oi] — >■ [02] 

meaning that for any types oi and 02, map takes a function of type oi — >■ 02 
and a list of type [oi], and produces a list of type [02]. ([o] is our notation for 
a list type with elements of type o) . 
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Polymorphic functions are heavily used in real functional programs. In par- 
ticular, library functions are frequently polymorphic, since the types at which 
they will be needed are not known when the library is written. The standard li- 
brary contains many polymorphic functions such as map and foldr (which takes 
a binary operator and its unit, and combines the elements of a list using the 
operator). These polymorphic functions greatly simplify programming, for ex- 
ample, the sum of a list of integers xs can be computed as foldr (-I-) 0 xs, and 
the conjunction of a list of booleans bs can be computed as foldr (A) true bs. 

1.2 Background: Partial Evaluation 

A partial evaluator is a tool which takes a program and a partially known input, 
and performs operations in the program which depend only on the known parts, 
generating a specialised program which processes the remainder. For example, 
specialising foldr to the inputs foldr (-I-) 0 [x,y,z], where x, y and z are unknown, 
would generate the specialised program x + y + z + 0. Here the construction of 
the known list, and the recursion over it inside foldr, have been performed by 
the partial evaluator: only the actual computations of the sum of the unknown 
quantities remains in the specialised code. 

Partial evaluators can be classified into online and offline. Online partial 
evaluators decide dynamically during specialisation which operations to perform, 
and which to build into the residual program: an operator is performed if its 
operands are known in that particular instance. An offline partial evaluator 
processes an annotated program, in which the annotations determine whether 
an operator is to be applied or not. Offline partial evaluators are generally more 
conservative, but simpler and more predictable; we focus on this type in this 
article. 

As an example, we annotate the power function, which computes x^ , for spe- 
cialisation with a known value for n. We annotate each operator with a binding- 
time, S (static) or D (dynamic), and we write function application explicitly as 
@ so that we can annotate it. Operators annotated static are performed during 
partial evaluation. 

power n X = if^ n 0 

then Int^^ 1 

else X power@^ {n l)@‘®a; 

In annotated programs we distinguish between known static values, and the 
corresponding dynamic code fragment; in this example, since the result of spe- 
cialising power is code, the coercion Int^^ must be used to convert the static 
integer 1 to the correct type. 

Annotated programs can be interpreted by a partial evaluator, or compiled 
into a generating extension. This is a program which, given the partially known 
input, generates a specialised version of the annotated program directly. The 
generating extension of this annotated power function is itself a recursive func- 
tion, which computes the static operations directly, and generates code for the 
dynamic ones. Running the generating extension with the arguments 3 and “x” 
(a code fragment) produces the code fragment “x x x x x x 1” . Notice that, in 
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the generating extension, a static integer and a dynamic integer are represented 
by different types: the former by an integer, and the latter by a code fragment 
— for example, an abstract syntax tree. Thus coercions do real work. 

However, fixed annotations work poorly in large programs. Library func- 
tions in particular may be called in many contexts, with combinations of static 
and dynamic arguments which are unknown at the time the function definition 
is annotated. This motivates polychronic annotations^ containing binding-time 
variables, which are passed as parameters to annotated functions 0. Using poly- 
chronic annotations, we can annotate the power function as 

power l3i (32 n X = n 0 

then 1 

else X power Pi P 2 @^(n — 

where the least upper bound of two binding times is determined hy S < D. This 
version can be specialised to any combination of known and unknown arguments, 
but binding-times must actually be computed and passed as parameters in the 
generating extension, increasing the cost of specialisation somewhat. (We need 
not annotate the applications to binding-times, since these are always performed 
during specialisation). Notice also that many more coercions are needed, now 
that the binding-times are no longer known a priori. 

The binding-time behaviour of this function can be captured by a binding- 
time type, 



power:: 'iPi, P 2 -Int!^^ Int^^ 

in which each type constructor is annotated to indicate whether the correspond- 
ing value is known. Program annotations can be generated by inferring these 
types using a binding-time type system. Types must always be well-formed, in 
the sense that no static type appears under a dynamic type constructor. 



2 What about Polymorphism? 

When we try to incorporate polymorphic functions into this framework, we im- 
mediately run into difficulties. Consider, for example, a possible binding-time 
type for the map function: 



map :: Voi, a 2 -V/?i, /92-(ai 02 ) 

But not every instantiation of this type is well-formed: if either Pi or P 2 is D, then 
neither ai nor «2 may be instantiated to a static type, since this would produce 
an ill- formed type containing a static type under a dynamic type constructor. To 
capture such dependencies between variables, we add constraints to our binding- 
time types, which all instantiations must satisfy. Writing /3 > a for the constraint 

^ Also, confusingly, called “polymorphic”. 
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that if /3 is D, then a must be a dynamic type, we can give a correct type for 
map as 



map :: Voi, q; 2 -V/ 3 i, / 32 -(/ 3 i l> ai,/ 3 i > a2, P2 > ai ,/32 > 02) ^ 

(Ol — 02) [Q! 2 ]^^ 

These constraints have been used before [Z] , but did not appear in binding-time 
types since that paper did not consider polymorphism. 

Now consider an even simpler polymorphic function, 

twice f X = f@{f@x) 

The standard type of this function is Va.(a — )> a) — >■ a — >■ a, but for the purposes 
of specialisation we can be more liberal: we can allow the argument and result of 
/ to have different binding-time types, provided the result can be coerced to the 
argument type. Thus we also need a coercion or subtyping constraint a\ < 02, 
which lets us give twice the binding-time type 



twice :: Vai, a 2 -V/ 3.(/3 O ai , /3 O a2 , 02 < cti) => (ai — 0:2) cni 0:2 

However, there is more than one way that we might choose to annotate the 
definition of twice. 

We might expect that, just as we pass binding-times explicitly in annotated 
programs, we should pass types explicitly to annotated polymorphic functions. 
Annotating twice in this way would result in something like 

twice a\ tt2 (i f X = f@^{[a2 !->■ oi] (f@^x)) 

But notice that we need a coercion, which we have written as [02 1— >■ oi], between 
two unknown types here! The compiled code for a generating extension will 
need to construct representations of types during specialisation, pass them as 
parameters, and interpret them in order to implement such coercions. Because 
types may be complex, this may be expensive, and in any case we prefer to avoid 
interpretation in generating extensions. 

Therefore, we treat polymorphic functions differently. Rather than passing 
types as parameters, we pass the necessary coercion functions, one for each sub- 
type constraint in the function’s type. With this idea, the annotated version of 
twice becomes 



twice (3 f f X = f@^{f (f@^x)) 

where ^ implements the coercion 02 < ct\. At each call of twice, we can pass a 
specialised coercion function for the types which actually occur. 

3 Binding-Time Analysis 

Binding-time annotations are usually constructed automatically by a binding- 
time analyser. We specify our polymorphic binding-time analysis via a type 
system for annotated programs, which guarantees that operations annotated as 
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static never depend on dynamic values. Given an unannotated program, the 
binding-time analyser finds well-typed annotations that make as many oper- 
ations as possible static. This type-based approach builds on earlier work by 
Dussart, Henglein and Mossin [HTT] . which has been adopted for the Similix 
partial evaluator [2]. We favour a type-based approach because it is efficient, 
comprehensible, and extends naturally to handle polymorphism. 

We shall specify the binding-time type system for the smallest interesting 
language, and then discuss how it is used to infer annotations. 

3.1 The Binding-Time Type System 

We consider an annotated A-calculus with polymorphic let and one base type: 

e[Expression] ::= c\x\ let x = e in e I Xx.e I e@^(/> e | A/3.e | e 6 | A^.e | e 4 > 
b[Binding-time] ::= S \ D \ P \ bUb 
4 >[Coercion] ::= i | ^ | Int^^ \ p — P 

Here /3 is a binding-time variable, ^ is a coercion variable, x is a program variable, 
and c is a constant. 

In this simple language, only function application need be annotated with 
a binding-time, and only function arguments need be coerced. Constants and 
A-expressions are always static, and are coerced to be dynamic where necessary, 
let-expressions are always dynamic, but their bodies may even so be static since 
we use Bondorf’s CPS specialisation j^, which moves the context of a let into its 
body, where it can be specialised. Applications to binding-times and coercions 
always take place during specialisation, and so need no annotation. 

We have already seen integer coercions. A coercion pi — coerces a 
function with binding-time b\ to one with binding-time 62, applying coercion p\ 
to the argument and p2 to the result, l is the identity coercion. 

Binding-time types and constraints take the form 

T[Monotype] \:= a \ Int^ \ r — r 
c[Constraint] ::= b<b\b>T\p: t<t 

The complete set of binding-time type inference rules can be found in the 
appendix; here we focus on the rule for application: 

T; C I- ei : (n ^ ra)'’ T; C |- ea : rg C |- </> : rg < n C \- b t> n C |- 6 > ra 

r;C'|-(ei p €2): T2 

As usual in a binding-time type system, our judgements depend both on an 
environment F and a set of constraints C . Notice, however, that our subtype 
constraints include the coercion that maps one type to the other. Thus, from the 
constraint set C, we infer which coercion p converts T3 to ti . Notice also that we 
include >-constraints to guarantee that the type of the function is well-formed. 
Finally, the annotation on the application is taken from the type of the function. 

Our constraint inference rules, with judgements of the form C \- c, can 
be found in the appendix. They are mostly standard, with the exception that 
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the rules for subtyping actually construct a coercion. For example, the rule for 
function types 

C ^ < Ti C \- 4>2'-T2 < T4 C \- bi < b2 

C \- (j)i <j)2 ■■ Ti -l"! T2 < T3 T4 

constructs a coercion on functions from coercions on the argument and result. 
Where possible, we use the identity coercion 

C \- i : T < T 

which can be removed altogether by a post-processor. We restrict the coercions 
in C to be distinct coercion variables; thus we can think of C as a kind of 
environment, binding coercion variables to their types. 

As in the Hindley-Milner type system, let-bound variables may have type 
schemes rather than monotypes. Type-schemes take the form 

^[Qualified type] ::= r | g 7 
q[Qualifier] ::= 6<6|6[>r|T<r 

Tr[Poly chronic type] ::= 7 | V/3.7r 
a[P olymorphic type] ::= tt | Va.cr 

We give a complete set of rules to introduce and eliminate type-schemes in the 
appendix; note that although our rule system is not syntax-directed, it is easy 
to transform it into a syntax-directed system because of the restriction on where 
type schemes may appear. Here we discuss only the rules which are not standard. 

Notice that qualifiers are almost, but not exactly, the same as constraints. 
The difference is that sub-type qualifiers t\ < T2 do not mention a coercion. 
Looking at the rules for introducing and eliminating such a qualifier 

A; C,g:Ti < T2 |- e : 7 T; C |- e : Ti < T2 ^ 7 C \- < T2 

P]C \— A^.e : Ti < T 2 7 T; C |- e 0 : 7 



we see why: the coercion in the constraint becomes the bound variable of a 
coercion abstraction; it would be unnatural to allow bound variable names in 
types. That we ‘forget’ the coercion doesn’t matter: it can be recreated where it 
is needed by the elimination rule. 

The rules for generalising and instantiating type variables are standard, 
except that we only allow instantiation with well- formed types. The rules for 
binding-time variables just introduce binding-time abstraction and application: 



T;C'|-e:7 

T; C h A/3.e : V/3.7 



(3iFV{C,P) 



T; C I- e : V/3.y 
r; C h e & : j[b/f3] 



Given any unannotated expression which is well-typed in the Hindley-Milner 
system, we can construct a well-typed annotated expression by annotating each 
application with a fresh binding-time variable and a fresh coercion variable, 
moving constraints into qualified types, and generalising all possible variables. 
But this leads to polymorphic definitions with very many generalised variables, 
and very many qualifiers. In the remainder of this section we will see how to 
reduce this multitude. 
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3.2 Simplifying Constraints 

Before generalising the type of a let-bound variable, it is natural to simplify 
the constraints as much as possible. Simplification of this kind of constraint is 
mostly standard m, except that we keep track of coercions also; essentially 
we use the constraint inference rules in the appendix backwards, instantiating 
variables where necessary to make rules match. For example, we simplify the 
constraint ^ a < Ini’ by instantiating a to Int^ and ^ to IniP^ , where /3 is 
fresh, and then simplifying the constraint to f 3 < b. Simplification of this kind 
does not change the set of solutions of the constraints. 

We use two non-standard simplification rules also. Firstly, whenever we dis- 
cover a cycle of binding-time variables ( 3 i < • • • < / 3 n < / 3 i) we instantiate each 
Pi to the same variable. We treat cycles of type variables similarly, which much 
reduces the number of variables we need to quantify over. Secondly, we simplify 
the constraints {D l> : ai < 02} by instantiating 02 to ai and ^ to this 
preserves the set of solutions because both ai and «2 have to be well-formed 
types annotated D at the top-level, and one such type can be a subtype of 
another only if they are equal. 

Simplification terminates, which can be shown by a lexicographic argument: 
each rule reduces the size of types, the number of >-constraints, the number of 
Us to the left of <, or the total number of constraints. 

3.3 Simplifying Polymorphic Types 

The simplifications in the previous section preserve the set of instances of a 
polymorphic type. That is, if we simplify a type scheme a\ to a type scheme CT2, 
then any instance ri of cti is guaranteed also to be an instance of (T2. But we 
can go further, if we guarantee only that there is an instance T2 of ct 2 which is a 
subtype of ti. This still enables us to use a polymorphic value of type CT2 at any 
instance of Ci, provided we introduce a coercion. For example, we can simplify 
the type of the power function from P2, Pa-iPi < Pa,P2 < Ps) => Int^’ 

Int^^ — IntP^ to yPi, P2-IniP’ IniP'^ these two types do not 

have the same instances, but any instance of the first can be derived by coercing 
an instance of the second. The second type has fewer quantified variables and 
coercions, and is therefore cheaper to specialise. 

This subtype condition is guaranteed by ensuring that variables occurring 
negatively in the type are only instantiated to smaller quantities, while variables 
occurring positively are only instantiated to larger ones. Moreover, simplifica- 
tion must not increase the binding-time of any program annotation, otherwise it 
would lead to poorer specialisation. Positively occurring binding-time variables 
therefore cannot be instantiated at all. Dussart et al. | 7 ] simplify by instantiat- 
ing non-positive binding-time variables to the least upper bound of their lower 
bounds (as in the power example above). 

In the presence of polymorphism, we instantiate type variables also. We 
might treat non-positive type variables in the same way that Dussart et al. 
treat binding-time variables, but this would introduce least upper bounds of 
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type variables. This would be problematic for us, since we pass coercions and 
not types as parameters during specialisation: while it is straightforward (if ex- 
pensive) to compute the least upper bound of two types, computing the least 
upper bound of two coercions would be far harder. But in two special cases, we 
can instantiate non-positive type variables to smaller types without needing least 
upper bounds. 

Firstly, if ^ : oi < 0:2 is the only constraint imposing a lower bound on 
«2, and «2 is non-positive, then we can instantiate 02 to ai and ^ to t. We also 
must insist that a\ and 0:2 are forced by the same set of binding-times; otherwise 
unifying them might make ai more dynamic. 

Secondly, if a\ and 0:2 are both non-positive, have the same set of lower 
bounds, and are forced by the same binding-times, then they must take the 
same value in the least solution of the constraints, and we can unify them — 
even though we cannot express this least solution without least upper bound. 

But there is another way to simplify constraints on type variables: we can 
instantiate non-negative type variables to larger types! This does potentially 
make some types more dynamic, but no binding-times, and it is the binding- 
time annotations which determine the quality of specialisation, not the types. 
We can do this in cases analogous to the two above, except that we need not 
be concerned with the binding-times which force type variables, since we expect 
to make type variables more dynamic. This process is specified formally in the 
appendix. 

This form of simplification terminates since each step eliminates one variable. 

For example, the type inferred for the map function, after simplifying binding- 
times, is 

Vtti, 02 : C«3j Ct4i 05-V/3 i, /32- 

(/3l > Oi, /?! I> 02) /?2 l> O3, /?2 l> 04, 03 < Oi, 02 ^ O4, 05 < OL4) => 

(oi —>-^1 02) [03]^^ [04]^^ 

(where 05 is a type variable internal to the definition of map) . 04 has two lower 
bounds, so cannot be reduced, while oi cannot be reduced to its only lower 
bound 03 since /?i > a\, but / 3 i does not force 03. However, 02, 037 and 05 are 
all non-positive and have unique upper bounds, so we can increase all three to 
their upper bounds and simplify the type to 

Voi, q;2.V/3i, /32-(/3i I> oi, ( 3 \ \> 0 . 2 , /32 l> oi, /32 l> 02 ) ^ 

(oi 02) [02]^^ 

The number of coercion parameters is decreased from three to zero. 

4 Handling Recursion 

We have implemented this binding-time analysis in a prototype partial evalua- 
tor for polymorphic programs HU. Handling recursive programs, in particular, 
forced us to introduce hand annotations which differ from those required in a 
monomorphic setting. 

Consider the annotated power function: 
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power Pi P 2 n X = n 0 

then 1 

else X poyjgf P 2 @^{n — l)@'^x 

The specialiser unfolds function calls, so specialising this definition to a static 
value for n produces a compact expression — for example, 

power S D 3 “x” = “x x x x x x 1” 

But if n is dynamic, then unfolding would produce an infinite residual program: 

power D S “n” 2 = “if n = 0 

then 1 

else if n — 1 = 0 
then 2 
else ...” 

The standard solution is to generate a recursive residual program instead: 

power D S “n” 2 = “power 2 n 

where power 2 n = if n = 0 

then 1 

else 2 * power 2 {n — 1)” 

Annotated expressions which are specialised to create residual function defini- 
tions are called program points, but various strategies have been used in the 
literature to decide which expressions to treat as program points. We have cho- 
sen to indicate program points explicitly via a hand-annotation pp. Thus we 
write the annotated power function as 

power Pi P 2 n X = pp^^ if^^ n 0 

then 1 

else X pQyjgf P 2 @^{n — 

In the standard (monomorphic) setting, specialising a program point always 
creates a new residual definition; program points are never unfolded. In our 
setting, when binding-times are not fixed in advance, this would be too inflexible. 
Whether the program point in this example should be unfolded depends on 
the binding-time of n, which is Pi. Thus we annotate pp constructions with a 
binding-time, which indicates whether a residual function definition should be 
created or not. 

However, the programmer does not write annotated programs. He writes a 
source program, which is transformed into an annotated one by the binding- 
time analyzer. Since the programmer cannot write binding-times directly, we 
need to provide a different way to control the binding-time which is attached to 
a pp. Our solution is to give pp an extra argument in the source language: an 
expression whose top-level binding-time is used to annotate the program point. 
In this example, since the program point is controlled by the binding-time of n, 
we write 
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power n X = pp n ( if n = 0 

then 1 

else X X power (n — 1) x) 

in the source language. If n is static, then the specialiser unfolds this definition 
as before. 

In fact, we use CPS-style specialisation, which moves static contexts into the 
branches of residual conditionals. For an example, see the “infinite” specialisation 
of power above, where the static 2x was moved into the branches of the generated 
conditionals, where it could be performed during specialisation. Our specialiser 
also moves static contexts into specialised program points, with the pleasant 
consequence that inserting a pp annotation does not change any binding-times. 
However, in the power example this leads the specialiser to generate infinitely 
many residual functions: one where the result is 1, one where it is 2, one where it 
is 4, etc. To prevent this happening, we must force the binding-time of the result 
to be D, if n is dynamic. In practice, every binding-time analyser sometimes 
makes too many operations static, causing partial evaluation to loop, and this 
must be prevented using user annotations m- But in our context, whether we 
should force an expression to be dynamic or not depends on other binding-times. 

We therefore add another annotation to the source language, force ei 62 - 
This evaluates to 62, but is forced to be dynamic if ei is dynamic. The binding- 
time analyser transforms this into a suitable coercion; force does not appear in 
annotated programs, it only steers the result of BTA. Using force, we can write 
the power function as 

power n X = pp n ( if n = 0 

then 1 

else force n x x power (n — 1) x) 

which is then specialised as in the examples above. 

These annotations force a binding-time to be dynamic, if a type is dynamic. 
We introduce a new form of constraint, r l> 6, to express this. (Previously we 
used constraints between types and types, binding-times and types, and binding- 
times and binding-times, but we had no way to constrain a binding-time based 
on a type). This constraint is satisfied if the top-level binding-time of t is less 
than 6: 



C ^ 5i < 62 C \~ b\ ^ h 2 
C I- Int^^ o &2 C I- n t 2 o 62 

Our implementation uses these rules to simplify constraints of the new form, but 
is not yet able to solve constraints a\>b involving a type variable, if any remain 
after simplification. We do not expect any fundamental difficulties in doing so, 
but for now we accept the mild restriction that a pp or force annotation in a 
polymorphic function definition may not be controlled by an expression whose 
type is just a type variable. This restriction guarantees that all such constraints 
can be simplified using the rules above, and has not proved awkward in practice. 
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5 Discussion 

Polymorphism is particularly important for programs made up of many mod- 
ules. In earlier work on specialising modules IMOl we discovered we needed 
polymorphic binding-time analysis, which directly inspired this work. 

Our analysis is built on Henglein et al’s earlier polychronic analyses [l3j 
|7|. Our extensions treat polymorphic types, introduce CPS specialisation, and 
consider hand annotations necessary to control the BTA. Consel et al developed 
a polychronic binding time analysis based on types and effects, similar in spirit to 
Henglein et al’s |4]. Binding-time analysers for polymorphic programs have also 
been developed based on abstract interpretation PH2H, although this approach 
is now little used in practice. 

In parallel with our own work, Glynn et al. generalised Henglein’s BTA to 
polymorphic programs, representing constraints by boolean formulae. This en- 
ables them to use a standard BDD package for efficient constraint solving. How- 
ever, they have not implemented a corresponding specialiser (which tends to 
have an impact on the BTA in turn), and their analysis is currently applicable 
only to non-strict languages [B| . 

This paper considers only parametric polymorphism, without overloading. 
We hope to extend our system to handle overloading based on Haskell classes 
1231 . Another important extension is to handle recursive datatypes: we considered 
these in a slightly different context in m- 

A much more detailed description of this work, including a complete specifi- 
cation of the associated partial evaluator, can be found in Heldal’s thesis m- 

6 Conclusion 

Polymorphic typing is integral to widely used functional programming languages 
such as ML and Haskell, and has also been adopted in other languages such as 
Mercury [22\ . Polymorphic binding-time analysis, such as ours, is vital if program 
specialisation is to be applied to such languages in practice. 
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A Appendix: Binding-Time Rnles 



r,x:a,r'-,C \- X : a P-,C \- c Int^ 



C |— Ti wft r, X’.TV, C |— e : T2 
T; C I- \x.e : (n T 2 ) 



F; C I- ei : (ri rj)'’ F; C |- 62 : rs F |- 0 : T3 < n F |- fe > n F |- 6 > T2 

F;F|- (ei @>62 ) :t 2 



F; F |— ei : (T F, x\cr, F |— 62 : r 
F; F |— let a: = ei in 62 : T 



Fig. 1. Syntax directed binding-time rules for expressions 



F;F|-e:7 
F; F I- A/3.e : V/l.y 



PiFV{C,P) 



F;F|-e:V/3.7 

F;F|-e6:7[&//3] 



F; F, ?)i < 62 |— e : 7 F; F, 6 > r |— e : 7 F; F, ^:ri < T2 |— e : 7 
F; F |— e : 61 < 62 7 F;F|— e:fel>T=^7 F; F |— \f.e : ri < T2 7 



F; F I- e : &i < &2 ^ 7 F |- 5i < &2 F;F|-e:b>T ^7 F|- 6 l>r 
F;F |- e : 7 F ; F e : 7 



F ; F |— e : n < T 2 ^ 7 F |— 4>:ti < T2 
F;F |- 6 0:7 



F; F I- e : Vq.ct « T Fv(C, F) F; F |- e : cr[r^] 



Fig. 2. Non-syntax directed rules 
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C\-bi<b2 

C,c\- c C\- l:t<t (7 |- : Int”^ < Int”^ 

C \— 4>i:T3 < n C |— 4>2-T2 < T4 C |— 6 l < 62 
C \— 4>1 (f)2 '■ Tl — T2 < T3 T4 

C^|-&1<&2 Cl-&l<fe2 

C I- 61 > c I- > r c\-bit> n ra 



C I- & < fe C I- 5 < fe C I- 6 < D C I- ft < U/3i 



g I- ft < ft C I- ft < ft 
g |— /3i U ft < ft 



Fig. 3. Constraint inference rules 



g |— a wft C \— Base^ wft 



C |— n wft C \— T2 wft C \— b \> Tl C \— b \> T2 
C |— Tl — T2 wft 



Fig. 4. Well-formedness of types 

Each time one of the rules below is applied, the constraints must first be normalised 
and the set of force constraints must be closed using the following rule: 

{/JOaijftQi <a2}~~>{/3l>o;i,/3>a2,^ :o:i < 0 : 2 } 

To simplify a type r and constraint set C in an environment F : 

13 i (|r|- U FV{r)) ^ C ^ C0[I3 := U^.ec<^ft]; /? := 

a i (|r|- U FV[F)) A g<c = {} A g>c C Coci 
=> g, ft oi < a ^ C[a := ai]; a := ai, ft= t 

0:1,02 ^ (|t| U FF(F)) a g<cKl — g<CK 2 A g>CK;^ = g>CK 2 
=> g ^ g[oi := 02]; Oi := 02 

o^ (|r|+UFF(r))A g„< = {} 

=> g,^ : o < oi ^ g[o := oi];o := oi,^ := t 

01,02 ^ (|r|+UFF(r)) A g„i<=g.2< 
g ^ g[oi := 02]; Oi := 02 

where 

g </3 = {ft Ift < /3 e g} g /3 = g - (ft < /? Ift € 1 } 

g<« = (oilft 01 < O e g} gc„ = (6|6 > O e g} gc< = (oilft o < 01 € g} 



Fig. 5. Increasing and decreasing variables 
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Abstract. We argue that a compact right-associated binary number 
representation gives simpler operators and better efficiency than the left- 
associated binary number representation proposed by den Hoed and in- 
vestigated by Goldberg. This representation is then generalised to higher 
number-bases and it is argued that bases between 3 and 5 can give higher 
efficiency than binary representation. 



1 Introduction 

The archetypal number representation in the pure lamda calculus is Church nu- 
merals, where a number n is represented as a combinator that applies a function 
n times to its argument, so for example 3 is represented as Xfx.f (/ (/ a;)). The 
definitions of addition, multiplication and raising to power are extremely simple 
when using Church numerals. However, Church numerals are not very compact 
and the operations, though simple, are quite costly, den Hoed suggested a 
compact representation of binary numbers, where a binary number bn ■ ■ ■ &i&o 
is represented as XxqXi.xi,o x^^ . . .X},^ or, equivalently, XxqXi.{{xi,^^ Xb^) ■ ■ -Xb„). 
This representation is, hence, left-associated. 

Given this as a challenge, Mayer Goldberg |2] has shown that efficient op- 
erators exist for this representation. However, we believe we can achieve better 
by using a right-associated representation and introducing one more variable to 
mark the end of a bit sequence: 0 is represented by XzxqXi.z and bn-.-bibo, 
where 0 is represented by XzxoXi.Xb„ (xb^ (■ ■ ■ {xb„ z)). 

We use standard lambda calculus notation: Identity function: I = Xx.x^ 
booleans: T = Xxy.x, F = Xxy.y, tuples: [ei,...,e„] = Xx.x ei ... e„ and 
projections: = Xt.t{Xxi ■ ■ ■ Xn-Xk). The identity function is / = Xx.x. We use 

the notation |"n] to mean the representation of the number n. Examples: 



[ 0 ] = XzxqXi.z 

[1] = XzXqXi.Xi z 

[5] = XzxqXi.xi {xo {x\ z)) 



D. Bj0rner, M. Broy, and A. Zamulin (Eds.): PSI 2001, LNCS 2244, pp. 205- 121^ 2001. 
(c) Springer-Verlag Berlin Heidelberg 2001 
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We note that this representation, like most binary representations, allow leading 
zeroes. For example, 0 can be represented as \zxqX\.xq x as well as \zxqX\.z. 
We want to avoid introducing leading zeroes. Goldberg builds this into the 
operators, but we define a separate operator that is applied when needed. 

2 Basic Operations on Numbers 

Shifting a binary number up by one bit is easily done in constant time: 
t = Xbn.XzxQXi.b xq x\ (n z xq x\) 

Single bits are represented as 0 = T, 1 = F. For brevity and slightly better 
efficiency, we will often use specialised versions of f: 



to = Xti.XzxqXi.Xo {n z Xq Xi) fi = Xti.XzxqXi.Xi (n z Xq xi) 

We can make a function that finds the least significant bit in a number by 



Isb = Xn.n T (Xx.T) (Xx.F) 



The idea in this operator is that we apply a number to three terms: One for han- 
dling the empty bit string, one for handling the case where the least significant 
bit is 0 and one for the case where the least significant bit is 1. 

We define, in a similar way, operators for stripping leading zeroes and dividing 
a binary number by 2: 



strip = Xn.Trf (n Z A B) where 

z =[roi,T] 

A = Xp.p {Xnz.[z [0] (to n),z]) 
B = Xp.p (Anz.[ti n,F]) 



t = An.7r| {n Z A B) where 

z^[roi,roi] 

A = Xp.p (Anm.[to n,n]) 

B = Xp.p (Anm.[ti n,n] 



For the .strip operator, we build a pair that contains the most compact represen- 
tation of the bits that have been treated and an indication if this is the empty 
bit sequence. Finally, we use to extract the final result from the pair. For 
division, the pair contains the whole number and the number divided by 2. 

An adequate number system needs operators for zero-testing, increment and 
decrement. We make these using the same techniques as above: 



zero! = Xn.n T I (Xx.F) 



succ = An.7r| [n Z A B) where 

^ ^[rouii] 

A = Xp.p (Anm.[to ^]) 

B = Xp.p (Anm.[ti n,to w]) 



pred = An.7r| {n Z A B) where 

Z ^[[01,(01] 

A = Xp.p (Anm.[to i^]) 

B = Xp.p (Anm.fti n,fo 



pred can introduce a leading zero if the number is a power of two. 



An Investigation of Compact and Efficient Number Representations 207 



3 Other Number Bases 

It is easy to generalise the above representation to other number bases. If we have 
an n-digit number d„_i . . .dido (where d„_i > 0) in base b, we can represent 
this as XzxqXi . . .Xn-i.Xd„ (xd^ (■ • ■ z ) . . .)). 0 is, of course, represented 

as XzxqXi . . .Xn-i-z. The operations are also easily generalised: 

h = Xn.Xzxo ■ ■ ■ Xb-i-Xi (n z xo ■ ■ ■ Xb-i) 
t = Xdn.Xzxo ■ ■ ■ Xb-i-d xo Xb-i {n z xo Xb-i) 

where a digit d for the general f operator is represented as Axq ■ • • Xb-i-Xd- The 
Isb operator is replaced by an Isd (least significant digit) operator: 

Isd = Xn.n (Aa;o . . . Xb-i-Xo) {Xx.Xxq . . . Xb-i-Xi) . . . {Xx.Xxq ■ ■ ■ Xb-i-Xb-i) 

Digits are represented as above. The strip operator is simple to generalise, as are 
diving by the base (z.e., removing the last digit), the zero test and the successor 
and predecessor operators: 

strip = Xn.Trf (n Z Aq ... Ab-i) where 

z =[roi,T] 

Ao = Xp.p {Xnz.[z [0] (to n),z]) 

Ai = Xp.p {Xnz-Wi n,F]) , z>0 

t = An.7r| {n Z Aq ... Ab-i) where 

Z ^[[01,(01] 



Ai = Xp.p (Anm.[ti n, n]) 




zero! = Xn.n T I {Xx.F)^~^ 




succ = An.7r| {n Z Aq ... Ab-i) 

z ^[[oUil] 


where 


A, = Xp.p (Anm.[t, n,ti+i n]) 
Ab-i = Xp.p {Xnm.[tb-i n,to m]) 


,i < b — 


pred = An.7r| {n Z Aq ... Ab-i) 


where 


Z ^[[01,(01] 

Ao = Xt.t {Xnmz.\\o n,tb-i 

Ai = Xt.t (Xnmz.[fi n, n]) 


, z > 0 



4 Comparing Different Number Bases 

Using he representations shown above, each digit in a base b number is repre- 
sented by a variable and an application. This could lead us to believe that we can 
get arbitrarily compact representations by choosing higher number bases. But 
an actual representation of a lambda term on a machine will have to represent 
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variables using a fixed alphabet, so the number of symbols needed to represent 
a variable depend on the number of different variables used. In order to be pre- 
cise about this, we will use de Bruijn notation: each occurrence of a variable 
is replaced by a so-called de Bruijn number that counts the number of lambda 
abstractions one has to pass in the syntax tree to get to the abstraction that 
binds the variable. Abstractions no longer name the bound variable. 

We still haven’t solved the problem, as we have replaced an unbounded num- 
ber of variables by an unbounded number of de Bruijn numbers. We can, however, 
replace these by number strings. A common representation of lambda terms uses 
unary representation for de Bruijn numbers such that, e.g., 3 is represented as 
sssz. This has the operational interpretation that z returns the value of the 
variable at the front of the current environment while s walks down one level in 
the environment. This idea is the basis of several abstract machines m m- 

We will explicitly bracket applications. By omitting the (redundant) opening 
bracket, we get a representation similar to reverse polish notation. Examples: 



lambda term de Bruijn notation compact representation 

Xx.x AO Xz 

Xxy.y X AAO 1 XXzsz) 

XzxqXi-Xi (xo {x\ z)) AAAO (1 (0 2)) XXXzszzssz))) 



Using this representation, an n-bit number is represented by a string of length 
2.5 X n -I- 1 on average for den Hoed’s left-associated representation. The right- 
associated representation requires and 2.5 x n-|-6 symbols on average to represent 
an n-bit number. Given that a base-5 digit and an application takes on average 
(5-1- 3)/2 symbols to write using our notation and that you need n * ln{2)/ln{b) 
base-5 digits to represent an n-bit number, we get the following measures of 
compactness for our base-5 representation: 



base 


23456789 10 


compactness 


2.5 1.89 1.75 1.72 1.74 1.78 1.83 1.89 1.96 



This table indicates that we will get the asymptotically most compact representa- 
tion if we use the base 5 representation. Since the above compactness measures 
depend somewhat on the exact details of the textual representation, we must 
take the numbers with a grain of salt. It is our guess that, for most reasonable 
measures, it will be better to use a base between 3 and 6 rather than base 2. 
A rough estimate is that the cost of processing a digit is roughly proportional 
to the number of different digits, so computational cost should follow a pattern 
similar to the compactness measures. If the cost per digit is kb + I, the cost of 
processing an n-bit number (in base 5) is (kb+l)ln{2) / ln{b) . Hence, the minimum 
is obtained when b{ln{b) — I) = l/k. This gives: 



An Investigation of Compact and Efficient Number Representations 209 



Ijk 


0 


1/4 


1/2 


2/3 


1 


3/2 


2 


3 


4 


minimum 


2.72 


2.95 


3.18 


3.32 


3.59 


3.97 


4.32 


4.97 


5.57 


optimal base 


3 


3 


3 


3 


4 


4 


4 


5 


6 



As can be seen, the minimum is always at b higher than 2. This indicates that 
it will always be better to use base 3 instead of base 2, and it may be better 
to choose an even higher base. Note that these measures are about asymptotic 
costs. For small numbers it will be better to use a small number base, such as 
binary or even unary. 



5 Balanced Ternary Representation 

An interesting number representation is balanced ternary. This variant base-3 
notation has digits (—1), “0” and “-I-” (1). This allows representation of neg- 
ative numbers without a separate sign symbol. Balanced ternary has been used 
in some early Russian computers, but lost to the simplicity of binary electronics. 
It may, however, well be good for number representation in the lamda calculus. 

Representing numbers in balanced ternary is very similar to ordinary ternary 
representation: We represent a balanced ternary digit string . . . to, where t„ yf 
0, as Xzx-xox+.xto (. . . {xt„ z)). Examples: 

[0] = XzX-XqX+.Z 

[1] = XzX-XqX+.X+ z 
[— 1 ] = XzX-XqX+.X- z 

\2] = Xzx-XqX+.X- {x+ z) 

[—5] = Xzx-Xqx+.x+ (x+ (x- z)) 

The operators are similar to those of normal ternary. 

= Xn.Xzx-Xox+.X- (n z x_ Xq x+) 
to = Xn.Xzx-Xox+.xo (n z X- xq x+) 
t _|_ = Xn.Xzx-Xox+.X-i- (n z X- xq x+) 
t = Xtn.Xzx-XQX+.t X- xo x+ (n z X- xq x+) 



where a ternary digit (trit) is represented as — = Xx-Xqx+.X-, 6 = Xx-Xqx+.xq 
and + = Xx-Xox+.x+. Operators for least significant trit, zero-testing, addition 
and subtraction are almost the same as for “ordinary” ternary numbers: 
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1st = Xn.n 6 (Ax.—) (Ax. 6) (Ax.+) 

zerol = Xn.n T (Xx.F) I (Xx.F) 

succ = An.7r| (n Z A_ Aq Al_|_) where 

^ ^[[ouil] 

A- = Xt.t (Anmz.[t_ n,to n]) 

Aq = Xt.t (Anmz.fto nj) 

A_|_ = Xt.t (Anmz.[t+ n,\_ m]) 

pred = An.7r| (n Z A- Aq Al+) where 

A- = Xt.t (Anmz.[t_ rr,t+ ™]) 

Aq = Xt.t (Anrnz.[to n,\_ n]) 

A+ = Xt.t (Anmz.[t+ n, to n]) 

Note the symmetry of succ and pred. They can now both introduce a leading 
zero. Since we now have negative numbers, an useful operator is negation. This 
is just a matter of replacing + by — and vice versa: 

negate = An.Azx_xox+.n 2 x+ xq x_ 

6 Binary Operators 

Some binary operators, like addition, require walking down two digit strings 
simultaneously. The representations we have shown so far aren’t geared to this, so 
we introduce yet another representation, which allows us to inspect one ternary 
digit at a time. The representation is similar to the previously shown, except 
that the variables z, x_, xq and x+ are abstracted at every digit rather than 
globally for all digits: 

[OJ = [ej = Azx-Xqx+.z 

\tn ■ ■ ■ tltoj = XzX— XqX+ ( \ tn ■ • • J ) , tn yf 0 

where e represents the empty digit string. We introduce operators fi, which takes 
a number n in the “normal” balanced ternary representation (|"n]) to the new 
representation ( [nj ) and its inverse fi: 

fi = Xn.n [Oj A- Aq A+ where 
A_ = An.Azx_xox+.x_ n 
Aq = Xn.Xzx-XQX+.XQ n 
A^ = Xn.Xzx-XQX+.x+ n 



fl n = n\0] (Am.t-f'll ni)) (Am.tof'H w)) (Aui.t+fU- m)) 
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The latter is given by a recursive equation. Solving this by using a recursion 
operator will make termination dependent on evaluation order. Hence, we delay 
the recursion until the right-hand side has been reduced. A similar trick was 
used in |4]: 

= U U where 

U = Xun.n (Au.fO]) (Aum.t_(u u m)) (Aum.to(w u m)) (Aum.t+(tt u m)) u 

The idea used in the following is that one of the arguments to a binary oper- 
ator is converted to the new representation by fi while the other is processed 
directly in the original representation. Hence, we define an operator ego that 
takes a number in the original representation and a number in the new repre- 
sentation and compares these for equality. We then define an equality operator 
eq = Xxy.eqo x (fl" y) that takes both arguments in the original representation. 

ego = Xn.n Z Aq where 

Z = Xn.zerol (JJ- n) 

A- = Xen.n F (Am.e m) (Xm.F) (Xm.F) 

Aq = Xen.n (e n) (Xm.F) (Am.e m) (Xm.F) 

A+ = Xen.n F (Xm.F) (Xm.F) (Am.e m) 

We, similarly, first define an addition operator addo that takes its second argu- 
ment in the new representation and use this to define add = Xxy.addo x (it J/)- 
At each step in the addition process, we have two trits and a carry (which is also 
a trit, represented as — , 0 or +). This can give results from —3 to 3, which are 
output as a trit and a carry, which is used for the next step. We find the trits in 
one number by applying suitable Z, A_, Aq and A_|_ to the number. The trits 
of the other number are obtained by a 4- way branch in each A-term, as in ego. 
The value of the carry is found by a 3- way branch (in each H-term below) . 

addo = Xn.C {n Z A_ Ao A_(.) where 
Z = Xnc.c {pred (JJ. n)) (IJ. n) (succ (JJ. n)) 

A_ = Xanc.n (H_ n) H _2 Bq 

Aq = Xanc.n {Bq n) Bq 

A+ = Xanc.n (H+ n) Bq H_|_ H +2 

H _2 = Am.e (to (a m A)) (t_^ {a m A)) (t_ (a m 6)) 

B- = Xm.c (t+ (a m — )) (f_ (a m 6)) (to (a m 6)) 

Bq = Am.t c (a m 0) 

= Am.e (to (a rn 6)) (t+ (a m 6)) (t_ (a m +)) 

B +2 = Am.e (t+ (a m 6)) (t_ (a m +)) (to (a m +)) 

C = Xan.a n 0 

We have here been a bit sloppy, as the B terms have free variables a and c which 
correspond to different bound variables depending on where the B is substituted. 
Subtraction is easily obtained by negating one argument before addition, so we 
just define the subtraction operator as sub = Xxy.add x {negate y). Multiplica- 
tion is simple to define using addition and subtraction: 
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mul = Xnm.n [0] Aq where 

A_ = Xn.sub (to n) m 
Aq = An.(to n) 

A+ = Xn.add (to n) m 

7 Benchmarks 

Our claims of efhciency above have, with the exception of the measure of com- 
pactness, been rather weakly argued on grounds of simpler operators. To remedy 
this, we have timed some calculations using different representations. To execute 
the calculations, we need a normaliser for the lambda calculus. We have elected 
to use a normaliser based on normalisation by evaluation and implemented in 
scheme jS]. This uses a call- by- value reduction strategy. 

The, admittedly simplistic, test we use is counting from 0 to 50000 using 
the succ operator. While this may not be representative of “real” calculations, 
we have in the majority of representations only implemented unary operators, 
which limits the scope of tests we can make on these. 



Representation 


time to count to 50000 


Right-associated binary 


6270 ms 


Base 3 


4380 ms 


Base 4 


4000 ms 


Base 5 


3900 ms 


Base 6 


4470 ms 


Balanced ternary 


4660 ms 



The time used to execute the benchmark drops by more than 30% from binary 
to base 3, but the advantage of further going to base 4 or 5 is less (around 10%). 

This supports the conjecture that the optimal base is higher than 2 and likely 
to be around 4 or 5. Balanced ternary is slightly slower than ordinary ternary, but 
that should be no surprise since the benchmark doesn’t use negative numbers. 

8 Conclusion 

We have investigated a number of different compact number representations 
for the lambda calculus, starting with the left-associated binary number system 
suggested by den Hoed. We argued that we get better calculation efficiency by 
choosing a right-associated representation and adding an explicit end symbol. 
We then found that number bases in the range 3-6 increase compactness and 
calculation efficiency over binary representation. 

While execution efficiency seems optimal at base 4 or 5, the operators become 
much bigger in these bases than in ternary: The size of the succ operator is ap- 
proximately quadratic in the number base, and the size of the addition operator 
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is approximately cubic in the number base. This may make base 3 the overall 
best choice. If ease of conversion to/from binary notation is important, a base-4 
representation might be preferable. 

The ease of handling negative numbers leads us to suggest using a balanced 
ternary number representation, for which we present some binary operators in 
addition to the unary operators we presented for the other systems. 

While we, arguably, gain efficiency over Goldbergs operators for den Hoed’s 
representation, this may not be an entirely fair comparison: After all, Goldbergs 
work was an answer to a challenge if he could make decent operations for a 
specific number system that was not designed for that purpose. Hence, he didn’t 
a priori have the freedom we have exploited of changing the number system to 
gain better efficiency. 
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Abstract. The paper is contributed to develop a family of observational 
equivalences for timed true concurrent models. In particular, we intro- 
duce three different semantics (based on interleaving, steps, and partial 
orders of actions) for timed trace and timed bisimulation equivalences 
in the setting of event structures with dense time domain. We study the 
relationship between these three approaches and show their discriminat- 
ing power. Furthermore, when dealing with particular subclasses of the 
model under consideration such as sequential and deterministic timed 
event structures there is no difference between a more concrete or a 
more abstract approach. 



1 Introduction 

An important ingredient of every theory of concurrency is a notion of equiva- 
lence between processes. Over the past several years, a variety of equivalences 
have been promoted, and the relationship between them has been quite well- 
understood (see, for example, [7|8| ). Two main lines which have been followed 
can be sketched as follows. The first aspect which is most dominant in the 
classical concurrency approaches is the so-called linear time - branching time 
spectrum. Here different possibilities are discussed to what extent the points of 
choice between different executions of systems are taken into account. In the 
linear time approach, the behaviour of a system is represented by the set of its 
possible executions {trace equivalence |H]), i.e. points of choice are ignored. At 
the other end of the spectrum, bisimulation equivalence unm considers choices 
very precisely. The other aspect to follow is whether partial orders between of 
action occurrences are taken into account. In the interleaving approach, these 
are neglected. Using more expressive system models like Petri nets or event 
structures, partial order based equivalences can be easily defined. 

Those equivalences were considered for formal system models without time 
delays. Recently, a growing interest can be observed in modelling real-time sys- 
tems which imply a need of a representation of the lapse of time. Several formal 
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methods for specifying and reasoning about such systems have been proposed in 
the last ten years (see |2I3J as surveys) . Whereas, the incorporation of real time 
into equivalence notions is less advanced. There are a few papers (see, for ex- 
ample, lelTefT^ ) where decidability questions of time-sensitive equivalences are 
investigated. In the above-mentioned studies, real-time systems are represented 
by timed interleaving models — parallel timer processes or timed automata, 
containing fictitious time measuring elements called clocks. 

In this paper, we seek to develop a framework for observational equivalences 
in the setting of a timed true concurrent model. In particular, we introduce 
three different semantics (based on interleaving, steps, and partial orders of ac- 
tions) for timed trace and timed bisimulation equivalences in the setting of event 
structures with dense time domain. This allows us to take into account processes’ 
timing behaviour in addition to their degrees of relative concurrency and non- 
determinism. We also study the interrelations between these three approaches 
to the semantics of timed concurrent systems. Furthermore, when dealing with 
particular subclasses of the model such as sequential and deterministic timed 
processes there is no difference between a more concrete or a more abstract ap- 
proach. This line of research is sometimes referred to as comparative concurrency 
semantics. 

There have been several motivations for this work. One has been the papers 
[11 511 7j which have developed concurrent variants of different observational 

equivalences in the setting of event structures. A next origin of this study has 
been given by a number of papers (see mm among others), which have 
extensively studied time-sensitive equivalence notions for interleaving models. 
However, to our best knowledge, the literature of timed true concurrent models 
has hitherto lacked such the equivalences. In this regard, the papers HUS] are 
a welcome exception, where different notions of timed testing have been treated 
in the framework of timed event structures. Finally, another origin has been the 
paper where equivalences based on step semantics have been investigated for 
a class of stochastic Petri nets with discrete time. 

The rest of the paper is organized as follows. The basic notions concerning 
timed event structures are introduced in the next section. The definitions of three 
different semantics (sequences of actions, multisets of actions, partial orders of 
actions) of timed trace and timed bisimulaton equivalences are given in the 
following three sections, respectively. In section 6, we establish the interrelations 
between the equivalence notions in the setting of the model under consideration 
and its subclasses. Section 7 contains some conclusions and remarks on future 
works. 



2 Timed Event Structures 

In this section, we introduce some basic notions and notations concerning timed 
event structures. 

We first recall a notion of an event structure m- The main idea behind 
event structures is to view distributed computations as action occurrences, called 
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events, together with a notion of causality dependency between events (which 
is reasonably characterized via a partial order). Moreover, in order to model 
nondeterminism, there is a notion of conflicting (mutually incompatible) events. 
A labelling function records which action an event corresponds to. Let Act be a 
finite set of actions. 

Definition 1 A (labelled) event structure over Act is a 4~tuple S = {E, <,#, 1), 
where 

— E is a countable set of events; 

— < C E X E is a partial order ( the causality relation ), 
of finite causes.- Ve G A « {e' G A | e' < e} zs finite; 

— ffQExE is a symmetric and irreflexive relation 
satisfying the principle of conflict heredity.- Ve, e',e" 
e #e"; 

— I : E — > Act is a labelling function. 

For an event structure S = {E, <, #, /), we define -^ = {E x E) \ {< U <~^ 
U ff) (the concurrency relation)] for e, f € E, we let eff^f efff A (Ve', /' G 
E o e' < et\f < fAe'fff' e' = eA/' = /) (the immediate conflict). For C C E, 
the restriction of S' to C is defined as S\C = (C, < n(C' x C), # fl (C x C),l |c)- 
We shall use O to denote the empty event structure (0, 0, 0, 0). 

Let C C E. Then C is left-closed iff Ve, e' G E o e G C A e'<e=^e'GC; 
C is conflict-free iff Ve, e' G C o ~<{e ff e'); C is a configuration of S iS C is 
left-closed and conflict-free. Let C(S) denote the set of all finite configurations 
of S. 

Next we present a model of timed event structures which are a timed exten- 
sion of event structures by associating their events with timing constraints that 
indicate event occurrence times with regard to a global clock. An execution of a 
timed event structure is a timed configuration, that consists of the configuration 
and the timing function recording a global time moment at which events occur 
and satisfies some additional requirements. 

Before introducing the concept of a timed event structure, we need to define 
some auxiliary notations. Let N be the set of natural numbers, and Rj the 
set of nonnegative real numbers. Define the set of intervals: Interv = {[di, ^ 2 ] | 
d\,d\ G R(|^, d\ < d2}- 

We are now ready to introduce the concept of timed event structures. 

Definition 2 A (labelled) timed event structure over Act is a pairTS = {S, D), 
where 

~ S = {E,<,ff,l) is a (labelled) event structure over Act and 

— D : E — > Interv is a timing function such that e! <s e minD(e') < 
minD(e) and maxl?(e') < maxD(e). 

In a graphic representation of a timed event structure, the corresponding 
action labels and time intervals are drawn near to events. If no confusion arises, 
we will often use action labels rather event identities to denote events. The 



satisfying the principle 

(the conflict relation 
G E o e e' < e” 
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<-relation is depicted by arcs (omitting those derivable by transitivity), and 
conflicts are also drawn (omitting those derivable by conflict heredity) . Following 
these conventions, a trivial example of a labelled timed event structure is shown 
in Fig. 1. 



TSi : 



[3,6] [4,7] 

a : ei ► b : 62 

# 

b : 63 

[4,5] 

Fig. 1. 



Timed event structures TS and TS' are isomorphic (denoted TS” ~ TS'), if 
there exists a bijection (p : Ets — > Ets' such that e <ts e' 4=^ (p{e) <ts' 
7’(e')> e #TS e' 4=^ (f{e) #ts' <p(e'), ^Ts(e) = and Dts{&) = 

DTS'{^i.e)), for all e, e' S Ets- 

Definition 3 Let TS = (S,D) he a timed event structure, C G C{S), and T : 
C — > RJ. Then TC = (C,T) is a timed configuration ofTS iff the following 
conditions hold: 

(i) y eGC o T(e) G D{e); 

(a) V e, e' G C « e <ts E T(e) < T(e'); 

(Hi) V e G (if \ C) « (max D{e) > T(e') for all e' G C) or 

(max D{e) > T(e') for some e' G C s.t. e! # e). 

Informally speaking, a timed configuration consisting of the configuration 
and the timing function recording a global time moment at which events occur, 
satisfies the following requirements: 

(i) an event can occur at a time when its timing constraints are met; 

(ii) for all events e and e' occurred if e causally precedes e' then e should tem- 
porally precede e'; 

{Hi) occurrences of events should not temporally prevent other events to occur 
except the events whose conflicting events have occurred before the events 
had time to occur. 

The initial timed configuration of TS is TCts = (0,0)- We use TC{TS) to 
denote the set of finite timed configurations of TS. 

To illustrate the concept, consider the set of the possible timed configurations 
of the timed event structure TSi shown in Fig. 1: {(0,0), ({ei},Ti), ({ 63 }, T 2 ), 
(|ei,e3},T3), ({ei,e2},T4) | Ti(ei) G [3,5]; T2(e3) G [4,5]; T3(ei) G [3,6], 
7 ^ 3 ( 63 ) G [4, 5]; T 4 (ei) G [3,5], Tffe^) G [4,5], Tffe^) < Tffe^)}. 

From now on, for TCi = (Ci,Ti),TC 2 = (<^ 2 , 22 ) G 'TC{TS) we shall write 
TCi TC 2 iff Cl C C 2 , T 2 IC 1 = Ti, and Ve G Ci Ve' G (C 2 \ Ci) . Tffe) < 
T 2 (e'). 
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3 Interleaving Semantics 

In this section, we define timed trace and timed bisimulation equivalences based 
on an interleaving observation on timed event structures. 

For this purpose we need the following notation. Let (Act,RQ) = {(a, d) | 
aGAct, d G R J } be the set of timed actions. 

In the interleaving semantics, a timed event structure progresses through a 
sequence of timed configurations by occurrences of timed actions. In a timed 
configuration TC\ = (Ci,Ti), the occurrence of a timed action (a, d) leads to a 

timed configuration TC2 = (C'2,T'2) (denoted TCi TC2), if TCi — S> TC2, 
C2 \ Cl = {e}, l{e) = a, and T2(e) = d. The leading relation is extended to a se- 
quence of timed actions from (Act, R(|")* as follows: TC ^ 

Lu{TS) = {wG (Act,R+)* I TCts TC for 
some TC G TC(TS)} is the ti-language of TS. As an illustration, consider the 
ti-language of the timed event structure TS\, shown in Fig. 1: {e, (a, di), (6, d2), 
(a, d3)(6, d4), (6, d5)(a, de) | di,d^ G [3,5], d2,d4,ds G [4,5], dg G [4,6], dg < 
d4j dg ^ dg} . 



Definition 4 Let TS and TS' be timed event structures. 

(i) TS and TS' are timed interleaving trace equivalent (denoted TS =u TS' ) 
iff Lu{TS) = Lu{TS'), 

i.e., two timed event structures are timed interleaving trace equivalent, if 
their ti-languages coincide; 

(a) TS and TS' are timed interleaving bisimilar (denoted TSg±hTS' ) iff there 
exists a relation B G_TC{TS) y. TCfTS') satisfying the following conditions: 
{TCts,TCts') G B and for all {TC,TC') G B it holds: 

(a) ifTC TCi in TS, then TC' TC'. in TS' and (TCi,TC'.) G B 
for some TC'^ G TC{TS'), 

(b) ifTC' TC'. in TS', then TC TCi in TS and (TCi,TC'A G B 
for some TCi G TC{TS), 

i.e., two timed event structures are timed interleaving bisimilar, if there 
exists a relation between their bisimilar timed configurations, among which 
the initial ones, such that the timed configurations obtained by occurring 
timed actions are also timed interleaving bisimilar. 

Considering the timed event structures shown in Fig. [21 we get TS3 =u TS4, 
while TS2 TS3, since, for example, (b,0)(a,0) G Lu{TS3) and (6, 0)(a, 0) ^ 
Lu{TS2). Further, we have TS^^^fTS^ but TS3^^^ TS4, because in the timed 
configuration of TS4, containing only the timed action (a, 1), the occurrence of 
a timed action (b, 1) is possible, but it is not always the case in TS3. 
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TS2 : 






TS3 










TS4 






TS5 


[0,1] 


[0.1] 


[1,1] 


[0,1] 


[0,1] 




[0,1] 


[0, 1] 


O' 


a 


# a 


# b 


a 


# 


b 


a 














— ti 












t±ti 












t£u 












^ts 












c 


1 


T 

b 




C 


1 


b 


[0,1] 


[0,1] 




[0,1] 


[0,1] 




[0.1] 


[0, 1] 



4 Step Semantics 



Fig. 2. 



In this section, we define a step observation on timed event structures to de- 
velop timed step trace and timed step bisimulation equivalences. Step semantics 
generalizes interleaving semantics by allowing timed actions to occur concur- 
rently with themselves. We show that timed step semantics gives a more precise 
account of concurrency than the timed interleaving one. 

Let A be an arbitrary set. A finite multiset M over A is a function M : A — > 
N such that | {a G A \ M{a) >0} |< oo. Let to denote the set of finite 

nonempty multisets over Act. We use (A1"^°*,Rq) = {{A,d) \ A G d G 

Rfj" } to indicate the set of timed steps. 

In the step semantics, timed configurations of a timed event structure change, 
if timed steps from ) are executed. In a timed configuration TCi = 

(Ci,Ti), the execution of a timed step (A,d) G leads to a timed 

configuration TC2 = {C2,T2) (denoted TCi TC2), if TCi TC2, C2 \ 
Cl = X, V e, e' G A o e ' e', 1{X) = A, Ve G A o T2(e) = d, where ^(A)(o) = 
|{e G A I /(e) = a}|. The leading relation is extended to a sequence of timed steps 

from (7W^"‘,R+)* as follows: TC TC’ ^ TC 

TC. The set Lts{TS) = {w G ( 7 W^=‘,R+)* | TCts TC for some TC G 
TC{TS)} is the ts-language of TS. Considering the timed event structure TSi, 
shown in Fig. 1, we have LtsiTS) = {e, ({a},di), {{b},d 2 ), ({a}, d 3 )({&}, ^ 4 ), 
{{b},d5){{a},de), {{a,b},d2) \ di,ds G [3,5], d2,di,d^ G [4,5], 4 S [4,6], c/3 < 
^4? dn Cl do} . 

Using ts-languages and leading relations of the form ^ — A*, we obtain timed 
step trace equivalence (denoted =ts) and timed step bisimulation equivalence 
(denoted exactly as the corresponding interleaving equivalences in Defini- 
tion 4. Timed step bisimulation is clearly stronger than timed step trace equiv- 
alence. 

To illustrate the concepts, consider the timed event structures, shown in 
Fig. Inland E] We have TSq =ts TSr, while TS 4 ^ts TS^, since, for example, 
({a, 6},0) G LtsiTS^) and ({a, 6},0) ^ LtsiTSi). Further, we get TS^G±^^TSs 
but TSq ^f^TSr, because in a timed configuration of TS' 7 , containing only a 
timed action ( 6 , 1 ), the execution of the timed step ({o}, 1 ) is always possible, 
but it is not the case in TSq. 
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TSe : 



TSr : 



TSs : 



[ 0 , 1 ] [ 1 , 1 ] [ 0 , 1 ] [ 0 , 1 ] [ 0 , 1 ] [ 0 , 1 ] 

a # b # b , a i) ^ i) 



±±ts 

^tp 



[ 0 , 1 ] [ 1 , 1 ] [ 0 , 1 ] 

^ ^ ^ b 



Fig. 3. 






b 

[ 1 , 1 ] 



5 Partial Order Semantics 



In this section, we consider several suggestions to define timed equivalence no- 
tions based on partial orders which take into account causality between timed 
actions. 



Define a timed partial order set as a timed event structure TP = {Stp = 
{Ej^p , , Dj’p) such that ^tp — 0 and Dpp : Epp — >■ Points, 
where Points = {[di,d 2 ] € Intern \ d\ = ^ 2 }- Isomorphism classes of timed 
partial order sets are called timed pomsets. 



TP 

We now consider leading relations of the form — >, where TP is a, timed pom- 
set. For TCi = (Cl, Ti), TC 2 = (C 2 , T 2 ) G TC{TS), we shall write TCi ^ TC 2 , 
ifrCi — 1 TC 2 and TP is the isomorphism class of (5 'ts [(C 2 \ Ci) , T 2 |(C 2 \Ci))- 

The set Ltp{TS) = {TP \ TCps ^ TC for some TC G TC(TS')} is the tp- 
language of TS. To illustrate the concept, we consider the tp-language of the 



timed event structure TSi, shown in Fig. 1: Ltp{TSi) = {(C,0), 



[di,di] 

a , 



[d2,d2] 

b , 



r , , , 

Ci [^ 4 ,(^ 4 ] 

[d2d2]’ “ — ^ b I di,d4 G [3,5], d2,ds G [4,5], 4 G [3,6], d4 < 4}- 
b 



TP 

Using tp-languages and leading relations of the form — >, we obtain timed 
pomset trace equivalence (denoted =tp) and timed pomset bisimulation equiva- 
lence (denoted ±±tp) exactly as the corresponding equivalences in Definition 4. 
Timed pomset bisimulation is clearly stronger than timed pomset trace equiva- 
lence. 



TSg : 



[ 0 , 1 ] 

a 




b # c 
[2,3] [2,3] 



TS'io : 

[ 0 , 1 ] [ 0 , 1 ] 

a H a 



b c 

[2,3] [2,3] 



TS'ii : 

[ 0 , 2 ] [ 0 , 1 ] 

a H a 



b c 

[2,3] [2,3] 



Fig. 4. 
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Considering the timed event structures, shown in Fig. |3] and [4[ we obtain 

[ 1 . 1 ] [ 1 . 1 ] 

TSg =tp TSio, while TS '7 ^tp TSs, since, for example, a — >• & G Ltp{TSs) 



A 

and a 



[ 1 . 1 ] 



b ^ Ltp{TS’j). Further, we have but TSgj^^pTSio, 

because in the timed configuration of TSg, containing only the timed action 
, , . . [ 2 ’ 2 [ . [ 2 . 2 ] 

(a, 1 ), the executions of the timed pomset b and the timed pomset c are 

possible, but it is not the case in T^io- 



6 Comparison of Equivalences 

The common framework used to define different observational equivalences al- 
lows us to study the relationships between the three induced semantics. The 
theorems we state in the section are a step towards a better understanding 
of the interrelations between interleaving, step, and partial order semantics. In 
particular, we will give the hierarchy for the equivalences and will establish that 
some of them coincide on particular subclasses of timed event structures. 

Theorem 1 Let TS and TS' he timed event structures. Then 

(i) TS =u TS' ^ TS =ts TS' ^ TS =tp TS'; 

(ii) TS±±^{TS' <= TS±±^J'S' <^= TS±±tpTS'. 

Proof Sketch. Immediately follows from the definitions of the equivalences. □ 

The timed event structures shown in Fig. 2-4 show that the converse impli- 
cations of the above theorem do not hold and that the six equivalences are all 
different. 

Now one can ask the obvious question what happens with all these equiva- 
lences if we restrict ourselves to some subclasses of the model under consider- 
ation. A timed event structure TS = {S = D) is called sequential, 

if 0 ; TS is deterministic, if e e' or e^'gc' => l{e) l{e') and 

T>Ts{e) n DtsW) 7 ^ 0- 

The next theorem shows that if we only consider timed event structures which 
represent timed sequential processes then all the three semantics of timed trace 
and timed bisimulation equivalences coincide. 

Theorem 2 Let TS and TS' be sequential timed event structures. Then 

(i) TS =u TS' ^ TS =ts TS' ^ TS =tp TS'; 

(ii) TS±±^{TS' ^ TS±±^J'S' ^ TS±±t^TS'. 

Proof Sketch. We shall show that TS =u TS' implies TS =ts TS' (the remain- 
ing cases are similar). Asssume TS =u TS'. Take an arbitrary sequence w = 
{Ai,di) . . . {An,dn) G Lts(TS). We have to show that w G Lts{TS'). Since TS 
is a sequential timed event structure, we have: \/0 < i < n o Ai = {ai\ for some 
G Act. According to our assumption, it holds (oi,(ii) . . . {a„,dn) G Lts(TS'). 
This implies w G Lts{TS'). An arbitrary choice of w guarantees TS =ts TS'. □ 
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The theorem below establishes that if we only consider timed event structures 
which represent deterministic processes then timed step and timed partial order 
semantics coincide. 



Theorem 3 Let TS and TS' he deterministic timed event structures. Then 
(i) TS =ts TS' ^ TS =tp TS'; 



(ii) TS±±,,TS' 



-tp 

■ TS^tpTS'. 



Proof Sketch. We shall prove that TS±±^^TS' implies TS±±^pTS' (the proof of 
item (i) is simpler). Let be a timed step bisimulation between TS = (S,D) and 
TS' = {S',D'). Take an arbitrary pair (TC\ = (Ci,Ti), TC 2 = {C 2 ,T 2 )) G B. 

W.l.o.g. suppose TCi = TCq TCi • • • 



({a„} d„) 



= TC, = 



(C(,r{) (n > 0). By the definition of timed step bisimulaion, we have: TC 2 = 
fCn-i fCn = TC'^ = {C'2, T^) and {fCi, fCi) G 



TCo fCi 



B for all 0 < t < n. Assume TCi = {Ci, Ti) and TCi = {Ci, %) for all 0 < z < n. 
Let Ci \ Ci-i = {ci}, and Ci \ Ci-\ = {e'} for all 0 < z < rz. We shall show by 
induction on n that (S'[(C'( \ Ci), |(c(\Ci)) ^ i.S'\{C! 2 \C 2 ),T!^ I(C'\C 2 ))- The 
case when rz = 0 is trivial. Suppose rz > 0. Two cases are admissible. If rz = 1, 
the result follows from the definition of a deterministic timed event structure. 
Assume rz > 1. It sufiicies to show that <5 Cj e' <$' e' for all 

^ ^ i, j S n such that z < j. Suppose a contrary, i.e. for some 1 < z, j < rz such 
that z < j it holds: Ci <5 Cj and e' -^s' e' (the converse case when Cj -g Cj 
and e' <s' e' is similar). W.l.o.g. assume j = z + 1. 

We shall show that there exists TC, 



{{o-i 



T' 



i + l } 

■ ^^+1 



for some d' G 



R+. 



i-\-l “ 

Take C'+i 



TC{TS') such that TC^-i 
= Cj+i. Further, take 



such that '7l+ilg._^ = and Tl+i(e') = 7('+i(e') = d' , 
where d' G D'{e'^) fl D'{e'j) such that di < d < dj (the existence of d' is guaran- 
teed by the definitions of a deterministic timed event structure, the set Intern 
and the relation — >• on timed configurations). We have to show that TCi_^_i = 
G TC{TS'). Since fc,_i G TC{TS') and d' G L»'(e') n L»'(e' ), the 

truth of item (i) of Definition 3 is obvious. Due to the facts that TCi G TC{TS') 
and di < d' , item (ii) of Definition 3 holds, by the definition of the relation — >■ on 
timed configurations. Since TCi+i G TC{TS') and d' < dj, it is straightforward 
to show the truth of item (iii) of Definition of 3. According to the construction 



of TCj_|_i, it holds: TCi-i 



({ai,ai+i},d') 



TC, 



i+1- 

definition of timed step 
Es such that / yf e^+i and 



Hence, we have TCi-i 

bisimulation. Then there exists an event / G 
Isif) = Oj+i. Consider all the possible relations between Cj+i and /. If e i+1 <S f 
{ci+i >s f), then (Q+i) is not a confuguration. If Cj+i -5 / or ez+i#s/, 
then we get a contradiction to the definition of a deterministic timed event 
structure. 



An arbitrary choice of {TCi, TC 2 ) guarantees TS =ps TS'. 



□ 
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The two rightmost timed event structures in Fig. 2 show that even for deter- 
ministic timed event structures there is a difference between timed interleaving 
and timed partial order semantics. 



7 Conclusion 

In this paper, we have given a flexible abstract mechanism, based on observa- 
tional equivalences which allows us to consider timed event structures as the 
basis of three different approaches (sequences of actions, multisets of actions, 
partial orders of actions) to the description of concurrent and real time systems. 
The results obtained show that these three semantics in general provide formal 
tools with an increasing power. Furthermore, when dealing with particular sub- 
classes of the model there is no difference between a more concrete or a more 
abstract approach. 

In a future work, we plan to extend the obtained results to other observational 
equivalences (e.g., equivalences taking into account internal actions) of timed 
systems. Some investigation on different timed concurrent semantics of testing 
equivalence which is located between trace and bisimulation equivalences in the 
linear time - branching time spectrum is now under way and we plan to report 
on this work elsewhere. 
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Abstract. Synchronisation is fundamental to concurrent programs. 
This paper investigates the security of information flow in multi-threaded 
programs in the presence of synchronisation. We give a small-step oper- 
ational semantics for a simple shared-memory multi-threaded language 
with synchronisation, and present a compositional timing-sensitive bi- 
simulation-based confidentiality specification. We propose a type-based 
analysis improving on previous approaches to reject potentially insecure 
programs. 



1 Introduction 

1.1 Motivation 

This paper focuses on the problem of program confidentiality, i.e., determining 
whether a given shared-memory multi-threaded program has secure information 
flow. The program runs on data partitioned on high (private) and low (public) 
security data, although a more general lattice of security levels can be considered. 
The program is not trusted, and the program’s low output is publicly available 
as well as, possibly, timing information about the program’s execution. Such 
a program might be received over the Internet and legitimately send its low 
output over the Internet such that the timing of the program’s Internet accesses 
is observable. 



1.2 Background 



The problem of confidentiality for various programming languages has been in- 
vestigated by many researchers including [liSI9l7l4ll4ltill5l22l 11120111211 12121171 
IlSIlOj . The issue of secure information flow has become especially important 
with the growing popularity of mobile code and networked information systems. 
For distributed programming, the use of multi-threaded programming languages 
has become extremely popular j^. However, in the setting of a shared-memory 
multi-threaded language, the majority of investigations in the area of secure in- 
formation flow, e.g., [lll2UI21ll7j do not treat synchronisation in the language. 
Although the security logic of |2j does consider synchronisation primitives, there 
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is neither a soundness proof nor a decision algorithm given for the logic. Because 
synchronisation is fundamental to concurrent programs, it is highly desirable to 
have a robust security specification and tools that aid in the design of secure 
programs with synchronisation. 

To bridge the gap, this paper presents a compositional bisimulation-based 
confidentiality specification for multi-threaded programs with synchronisation 
and proposes a type-based analysis improving on previous approaches to reject 
potentially insecure programs. 

1.3 Insecure Flows to Eliminate 

Let us exemplify the types of insecure information flow that are in the focus 
of this paper. Suppose ft. is a high security variable and I is a low security one. 
There are several ways to leak information from ft to the low-level observer 
(attacker). The simple program I := his an example of a direct flow. The program 
if ft = 1 then I := 1 else I := 0 features an indirect flow through branching on a 
high condition. 

The attacker may deduce secret information from the timing behaviour of 
the program. The program 

if ft = 1 then (while ft < Maxinteger do h := h + 1) else skip 

exemplifies a timing leak. Notice that the program does not operate on low 
variables. Nevertheless, assuming the program’s execution time is visible for the 
low-observer, this is clearly a potential leak. Indeed, in case the initial value 
of ft was 1 the program would take more time to execute than otherwise. The 
program 



if ft = 1 then (while True do skip) else skip 

is a variation of the timing leak called a termination leak. Observing the termi- 
nation of the program reveals that ft was not 1. 

Blocking a thread can change the observable behaviour of a computation, 
e.g., its termination behaviour. If blocking depends on high data, then the at- 
tacker might learn secrets through the observable behaviour. Concrete examples 
of synchronisation leaks are postponed until Section 0] where concrete synchro- 
nisation primitives will be available. 



1.4 Overview 

The rest of the paper is organised as follows. Section |2] introduces the syntax 
and semantics of a multi-threaded language. Section 0] motivates and specifies a 
bisimulation-based security definition. Section 0]gives a type system for detecting 
secure programs and shows its correctness with respect to the security defini- 
tion. Section 0] gives an example of secure programming with synchronisation. 
Section 0] concludes by discussing related work. 
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2 A Multi-threaded Language with Synchronisation 

To set the scene, let us begin by defining the syntax and semantics of a sim- 
ple multi-threaded language with dynamic thread creation and synchronisation. 
Semaphores are widely used as a synchronisation primitive in shared-memory 
languages. As pointed out by Andrews ([3, p.viii): “Semaphores were the first 
high-level coneurrent programming mechanism and remain one of the most im- 
portant. ” Semaphores are general enough to implement both mutual exclusion 
and condition synchronisation. In this section we introduce semaphore primitives 
and give a small-step operational semantics for the multi-threaded language. 

2.1 Semaphores 

A semaphore PD] is a special variable (call it sem) that can only be manipulated 
by two commands: wait(sem) and signal(sem). The value of sem ranges over 
nonnegative integers. Initially, the value is 0 for every semaphore. The wait(sem) 
command blocks until sem is positive. Once sem is positive, it gets decremented 
by 1. The signal(sem) command increments sem by 1. 

2.2 Semaphores by Busy Waiting 

One approach to introducing semaphores in the language is to use macrodefini- 
tions and define the synchronisation primitives by while-loop-based busy waiting 
(as in, e.g., g]): 

wait(sem) = (while sem = 0 do skip); sem := sem — 1 
signal(sem) = sem := sem -\- 1 

Although these definitions are intuitive, there are two major problems with them. 
First, a waiting process occupies the CPU with idle spinning. Also, delay and 
decrement must be a single atomic action. Otherwise two wait(sem) threads 
might succeed when the initial value of sem is 1! Atomicity may be hard to 
implement in a distributed setting (not to mention that timing behaviour will 
spin out of control since one atomic action no longer takes one time unit). Blocked 
waiting, which commonly underlies semaphore implementations, does not have 
the disadvantages above. It is important that we adapt blocked waiting, since the 
dynamics of thread (un)blocking in a program’s execution needs to be explicitly 
modelled due to its potential to affect the program’s security. 

2.3 Semaphores by Blocked Waiting 

In order to define blocked waiting, we will use a special pool of waiting processes. 
The idea is that blocked processes should be sleeping (as opposed to spinning in 
busy waiting) until the respective signal is sent. 

The syntax of the language is given in Figure [TJ Let C, D, E, . . . range over 
commands Com, and let u denote a vector of commands of the form {C\ . . . Cn)- 
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Vectors Zt, . . . range over Com = UngNCom", the set of thread pools (or 

programs). A state s G St is a finite mapping from variables (including special 
semaphore variables) to values. The set of variables is partitioned into high 
and low security classes, h and I will denote typical high and low variables, 
respectively. Define low-equivalence by si =l S 2 iff the low components of si 
and S 2 are the same. 

The small-step semantics is given by transitions between configurations, i.e., 
between pairs each containing a program and a state. The deterministic part 
of the semantics is defined by the transition rules in Figure |2] Arithmetic and 
boolean expressions are executed atomically by f transitions. The — > transitions 
are deterministic. There are two kinds of deterministic transitions: unlabelled 
and labelled. Labels are used in the semantics in order to propagate (un)blocking 
information. The general form of an unlabelled deterministic transition is either 
(C, s) — > which means termination with the final state s', or (C, s) —> 

(\C'D,s'\. Here, one step of computation that starts with a command C in 
a state s gives a new main thread C , a (possibly empty) vector of spawned 
processes it and a new state s'. Command fork(C, zt) dynamically creates a 
new vector of processes it which run in parallel with the main thread C . This 
has the effect of adding the vector of threads to the configuration. 

Let sem be a variable from the special set Sem of semaphore variables. The 

OL 

general form of a labelled deterministic transition is either (C, s) — > 

OL 

or ((7,5) — > (C",s') where the label a ranges over the set of possible la- 
bels a € {(S>sem, Osem | sem € Sem}. These labels correspond to blocking and 
unblocking upon a respective semaphore. The wait(sem) command emits the 
“block” label ®sem in case the value of sem is 0. Otherwise it decreases the 
value of sem. The signal(sem) emits the “unblock” label Qsem. The labels are 
propagated through the sequential composition to the top level. 

The concurrent part of the semantics is presented in Figure |3] The — ^ transi- 
tions are nondeterministic. The nondeterminism is resolved by the scheduler in 
a particular implementation. The scheduler might be probabilistic and history- 
dependent, but, aiming at scheduler-independent security, we make no assump- 
tions about peculiarities of a particular scheduler. The — >■ transitions have the 
form (Z^, w, s) — )> , rc', s') where configurations are equipped with queues of 

waiting processes w,w' : Sem — >■ Com. Whenever the top level receives a ®sem 
signal, the blocked thread is put in the end of the FIFO queue associated with 
sem. If the top level receives an Qsem signal, the first thread in the FIFO gets 
awakened or, in case, the FIFO is empty, the value of sem gets incremented. 

We can extract a simple model of the timing behaviour of multi-threaded 
programs from the small-step semantics. This is done by assuming that each 
— > transition takes a single unit of time to execute. This approach gives only 
a rough approximation of the actual timing behaviour, but simple extensions 
are possible in order to make it sensitive to the timing behaviour of particular 
commands (cf. [2]). 
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C ::= skip I Id := Exp \ Ci; C2 | if B then Ci else C2 
I while B do C I fork((7, 1?) | wait(S'em) | signal(S'em) 



Fig. 1. Command syntax 



|skip,s} 10, 

{Cl-,C2,s) ^ {C2,s'\ 

{B, 4, True 

|if B then Ci else C2, -> |Ci, s} 

{B, 4, True 

(while B do C, s} — > (C; while B do C, s} 



{exp, 4 tr 

{x := exp, s} — ■> ( 0 , [x := n]s} 

(Ci,s} -> {C[^,s} 
{Ci-,C2,s}^{{C[-,C2)^,s'} 
{B, s} 4 False 

(if B then Ci else C2, -t> (C 2 , s} 

(B, s} 4 False 

(while B do C, — > ((),s^ 



{sem, 4 tr n > 0 

(wait(sem), -t> {(), [sem := sem — l]s} 
(fork(C,:^),s} -> {C^,s} 

Qsem 

(signal(sem), — > ((),s^ 



{sem, 4 0 

0sem 

(wait(sem), — > ((),s^ 

a 

(Cl, -t> (C(, sO a G {ig)sem,Qsem} 
(Ci;C2,4 ^ {C{\C 2 ,s'] 



Fig. 2. Small-step deterministic semantics of commands 



[Ci, s} -fr (Zf, s'} 





{{Ci...C„),w,s}^ {{Ci...Ci- 

0sem 

(Ci,s^ ^ (C',sO 


l~dCi + l...Cr.),W,s'\ 
Wsem ~ ^ 


I(C1. 


■ • • Cn)-, W, • • • Ci — -\_Ci-\-l 


• • • Cri)i [Wsem •— 1^ ^ 




0sem 

(Ci,s^ ^ (C',sO 


Wsem ~ C 1^ 


I(C1- 


. . C„),W, ^ ((Cl . . . Ci_lC'Ci+l . . . C„C), [Wsem ■= l^]w , S'} 




Qsera 






(Ci,s^ -> {C',s'\ 


Wsem — 0 



((Cl . . . C„),w, s} — >• ((Cl . . . Ci_iC'Ci+i . . . C„),w, [sem ;= sem + l]s 0 



Fig. 3. Concurrent semantics of thread pools 
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3 Security Specification 

What is a secure program in the language we have just defined? This section 
focuses on defining confidentiality and motivating the chosen definition. 



3.1 Noninterference 

The central idea of extensional security, as opposed to intensional security, is 
that confidentiality should not be specified by a special-purpose security for- 
malism, but, rather, should be defined in terms of a standard semantics as a 
dependency property (more precisely, the absence of dependencies). If direct, 
indirect, and timing flows are considered then, intuitively, a program has the 
extensional noninterference property if varying the high input will not change 
the possible low-level observations, i.e., low inputs, low outputs and timing. This 
differs from intensional security which relies on particular security primitives 
that are only motivated by intuition rather than a mathematical justification. 
Many investigations have successfully pursued the extensional view, including 
[I7l22llll20lll2lll2l2ll7ll8ll6| for the justification of security analyses and veri- 
fication techniques for different languages. We follow the extensional approach 
and focus on the extensional security for our language. 

The main idea behind the bisimulation-based approach promoted by pu 
is to formalise the indistinguishability of the behaviours of two programs C 
and D for the attacker by C D, where is a low-bisimulation. Such an 
approach is flexible in the choice of an appropriate low-bisimulation (different 
low-bisimulations are available for different degrees of security) . For a given low- 
bisimulation the definition of security is simply: 

C is secure iff C C 

For our purposes we adapt a variation of the strong low-bisimulation El- 

Definition 1 Define the strong low-bisimulation to be the union of all sym- 
metric relations R on thread pools of equal size, such that if {C\ . . . Cn) R 
{Di . . . Dn) then 

Vsi =L S2ViVa.(Ci, Si) — <> \Tf',s'i} => 

3)^', s'2.<1A, S 2 l> ^ 0 ', s'a), R s[ =l s'^ 

where a € {e, (S>sem, Osem}. The security specification then is: 

Definition 2 Tf is secure 

One can show that the relation is transitive, but not reflexive. E.g., I := 
h I ■= h, which reflects the fact that the program behaves differently for the 
attacker, depending on the initial value of h. 
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The choice of this bisimulation allows for robust security. As argued in ca, 
strong low-bisimulation captures timing /i!owsl3 If two commands may have a 
different timing behaviour depending on high data (which would result in in- 
formation flow from high to low) then they are not low-bisimilar. Also, strong 
low-bisimulation is scheduler-independent. Thus, our notion of security is robust 
with respect to any choice of a particular scheduler. 

Thanks to the clear separation between deterministic and nondeterministic 
semantics, the underlying theory of is applicable to the new semantics, which, 
e.g, suggests a generalisation to probabilistic schedulers (although it is outside 
the scope of this paper) . Despite the fact that these features impose restrictions 
on what can be considered low-bisimilar, the choice of strong low-bisimulation is 
adequate (not too restrictive) for the type-based analysis proposed in Section |H 
We will prove that whenever a command is typable in our system, it is secure. 



4 Type-Based Security Analysis 

This section presents an automatic compositional analysis for certifying secure 
programs, extending and improving on previous approaches The sec- 

tion concludes by stating soundness results. 



4.1 The Type System 

The analysis is based on a type system that transforms a given program into 
a new program. If the initial program is free of direct, indirect and synchroni- 
sation insecure information flows then it might be accepted by the system and 
transformed into a program that is also free of timing leaks. Otherwise the initial 
program is rejected. The transformation rules have the form ct ^ : ^l, 

where cf is a program^ is the result of its transformation and ^l is the 
type of Tf'. The type S I is C^'’s low slice, i.e., essentially a copy of in which 
assignments to (and conditionals on) high variables have been replaced by skip’s. 
The low slice S I has no occurrences of h and models the timing behaviour of 
cf', as observable by other threads. 

The typing and transformation rules are presented in Figure The variables 
h and I have the types high and low respectively. Value literals n may be con- 
sidered as either high or low. An arbitrary expression Exp is considered high. In 
all but the lihigh rule, the transformed program is constructed compositionally 
using the same constructs as the original program. The information about the 
low slice of the new program is recorded in the typing. The command skip is its 
own low slice and therefore its own type. The rule Setjo^, prevents direct insecure 
information flows — the assignment I := h is not typable. The rule Sethigh types 
an assignment to the high variable with the low slice skip. The rules Expjoi„, Seq, 
Ifiow, Par and Fork propagate types compositionally. The guard of the while-loop 

^ Nevertheless timing attacks at the layer below our assumptions (using, e.g., non- 
atomicity of semantics steps (cf. Section [2.31 1 or cache behaviour jS]) are still possible. 
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[Exp] 

[Expio^j;] 

[Skip] 

[S6tiow;] 

[S6t/iij^/i] 

[Seq] 

[While] 

[Par] 

[Fork] 

[Wait] 

[Signal] 

[Ifio,i,] 

[If/iigh] 



h : high I : low n : t Exp : high 

Expi : low Exp2 : low 
op{Expi, Exp2) ■ low 

skip skip : skip 

Exp : low 

I := Exp ^ I := Exp : I Exp 

h := Exp h ■.= Exp : skip 

Ci^C[: Sh C 2 ^C 2 -. Sh 
Ci;C2 C'(;C' : Slv, SI2 

B-. low C^C' : SI 

while _B do C ^ while _B do C' : while B do SI 

Ci^C[-.Sh ... Cn ^ C; : Sir, 

{Cl... c„) ^{c[... c;) : {Sh . . . SL) 

Ci^C[-.Sh '^ 2 ^^' 2 -^h 
fork(Ci, ■^2) fork(C(, ■^'2) : fork(S'Zi, ^^2) 

sem : low 

wait(sem) ^ wait(sem) : wait(sem) 
sem : low 

signal(sem) ^ signal(sem) : signal(sem) 

B : low Ci^C'i: Sh C2 ^ C'2 '. Sh 

if B then Ci else C2 if -B then C( else Cj : if -B then Sh else SI2 

B : high Ci^Cj: Sh C2 ^ C'2 '. SI2 aljSh) = aliSh) = False 
if B then Ci else C2 ^ if B then C(; SI2 else Sh', C'2 '. skip; Sh', SI2 

Fig. 4. Security type system 



in the rule While has to be low in order to prevent the timing (and nontermina- 
tion) flow from the loop’s guard. The rules Wait and Signal guarantee that only 
low semaphores are used for synchronisation. 

In addition to the insecure flows exemplified in Section [H there are further 
ways to leak information through blocking. Synchronising on a high semaphore 
variable leads to (un)blocking of a thread and, clearly, may affect the termination 
behaviour of the program. As a consequence, neither wait(sem) nor signal(sem) 
on a high semaphore is allowed by the type system. The rule lihigh prevents 
indirect insecure flows and timing flows. An indirect flow might be performed 
through synchronisation on a low semaphore depending on a high guard, e.g., 
if h = 1 then wait(sem) else skip. Thus, the type system prevents from syn- 
chronisation in the branches of an if-on-high. Let al{C) be a boolean function 
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returning True whenever there is a syntactic occurrence of either an assignment 
to low variable I or a synchronisation primitive (wait or signal) in the command 
C and returning False otherwise. The condition al{Sli) = al{Sl 2 ) = False pre- 
vents indirect leaks. Both branches must be typable (i.e., they must have a low 
slice). For the transformed program to be secure (preventing timing leaks) it is 
also necessary that the two branches be low-bisimilar. This is achieved by cross- 
copying the low slice of one branch into the other (cf. Figure El). The slice of 
the overall command is the sequential composition of the slices of the branches 
prefixed with a skip corresponding to the time tick for the guard inspection. 



4.2 A Modification of the Cross-Copying Rule 

A modification of the rule Ifhigh might be used to guarantee that dummy compu- 
tation is inserted “evenly” and that it does not block useful computation within 
the branches of the resulting program. Such a rule makes use of the parallel com- 
position instead of the sequential one when cross-copying (cf. Figure El). Such an 
alternative rule is: 

B : high Ci ^ C[ ■. Sh C 2 ^ C'^ : Sh aljSh) = aljSh) = False 
high C 2 ^ if B then fork(C(; wait(sem), S'/2; signal(sem)) 

else fork(S'Zi; wait(sem), C2; signal(sem)) 

: skip;fork(S'?i; wait(sem), S'Z2; signal(sem)) 

where sem is a fresh (low) semaphore, unused elsewhere in the program. The 
use of the semaphore in the rule ensures that both main threads in each branch 
of the resulting code have terminated before passing the control outside the if. 
This is necessary to prevent potential changes in the order of execution of the if 
and the following commands. 

Interestingly, the alternative rule turns out to be less restrictive, as demon- 
strated in the following example. Let us denote loop = while True do skip. Con- 
sider the program on the left in Figure [3 Transforming the program by the 
rule If high (as in the type systems of [312]) gives a program that gets stuck 
with the dummy while-loop (which appears in the first position in the sequential 
composition in both branches). This implies that the fragment h := —h never 
gets to be executed. The result of the transformation is on the right in Figure H 
(In the examples we omit the low slices for simplicity.) As depicted in Figure [Sj 
the modified rule ff'high transforms the program into a program where the high 
computation (the fragment h := —h) is enabled while the dummy loop executes 
in parallel. 



4.3 Correctness of the Analysis 

The key to straightforward correctness proofs is the compositionality of the secu- 
rity property (Definition [2]) . In the standard security terminology, this is called 
the hook-up property m- Having the hook-up property facilitates modular de- 
velopment of secure code. 
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Fig. 5. Padding in rule Ihigh 




Fig. 6. Padding in rule 



Termination leak 



Padded transformation result 



if /i > 0 
then loop 
else h := —h 



if > 0 

then loop; skip 
else loop; h := —h 



Fig. 7. Example of applying Uugh 



Termination leak 



Padded transformation result 



if /i > 0 
then loop 
else h := —h 



^ if /i > 0 

then fork(loop; wait(sem), skip; signal(sem)) 
else fork(loop; wait(sem), h := — /i; signal(sem)) 



Fig. 8. Example of applying 



Clearly, an arbitrary context is not necessarily secure, i.e., the low- 
bisimulation is not a congruence. The program I := is an example of an 
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insecure ground context (recall that I := h I := h). Let us go through the 
program constructs of the language and investigate what constraints they im- 
pose for building secure contexts. We identify secure contexts and give a formal 
proof. 

Let [“*^] be a hole for a command vector and [•] be a hole for a singleton 
command. A context “*^2] is secure iff it has one of these forms: 

”*^2] ” = skip I h := Exp \ I := Exp {Exp is low) 

I [•!]; [*2] I if B then [*i] else [*2] {B is low) 

I while B do [*i] {B is low) | fork([*i], [V2]) | ([Vi][V2]) 

I wait(sem) {sem is low) | signal(sem) {sem is low) 

where a (boolean or arithmetic) expression Exp is defined to be low iff Vsi =l 
S2- 3 n. {Exp, si) 4, n & {Exp, S2l> i n. Otherwise, the expression is high. 

Theorem 1 (Secure congruence) Let and Tf 2 ^2- 

V'2] is a secure context, then ^^2] ct'2]. 

/f C[*i,*2l is an if-on-hiqh context C[*i,*2l = if B then [•il else [•2I fB is high), 
then C[Ci,C2] C[C(,C'^] provided Ci C2. 

Due to the separation of the semantics into deterministic and nondeterministic 
parts, we are able to reuse the proof of secure congruence for the language 
without synchronisation from HZ] since it only operates on the deterministic 
semantics. Adding the secure contexts wait(sem) and signal(sem) (for a low sem) 
poses no substantial problems. An immediate corollary is the hook-up result. 

Corollary 1 (Hook-up) IfTfi and Tf 2 o,re secure and "*^2] is a secure 

context, then C[cfi, ^^2] is secure. //C[*i,*2] = if B then [*i] else [*2] (B is 
high), then C[C'i,C2] is secure provided Ci C2. 

Proof. Assuming Tf i and Tf 2 are secure, we have Tf i for i = 1 , 2 . By 

the security congruence theorem C[C^i, C2] ^^2], i-e., C[C^i, ^^2] is 

secure. □ 

Since both the security property and the analysis are compositional, the cor- 
rectness proof is a simple structural induction. We have the following theorem. 



Theorem 2 



Corollary 2 (Correctness of the Analysis) Tf t' is se- 

cure. 

To see why the corollary holds, note that Theorem E] gives ^l. The 

symmetry and transitivity of entails t', i.e., is secure. 
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4.4 Soundness of the Transformation 

We have shown that the result of the transformation is secure, but what of its 
relation to the original program? Clearly, the padding introduced by the trans- 
formation can change the timing, but otherwise it is just additional “stuttering” . 
To make this point precise, let us define a weak (bi) simulation on configurations. 
Let \C, s] {C, s'^ hold iff \C, s) = {C , s'^ or {C, s] {C , s'K 

Definition 3 Define the weak simulation A (resp., bisimulation to be the 
union of all (resp., symmetric) relations R on thread pools such that ifT^Rl^ 
and \/sem. Wsem R Vsem then for all s, s' , w', C there exist D' and v' such that 

~d' R T 5 ',\/sem. R 



Lemma 1 A and ~ are reflexive, transitive and respected by all contexts (not 
necessarily secure), i.e., < is a precongruence and a is a congruence. 

Theorem 3 cf ^ Tf' : ^l ^ cf' . 

Proof. Induction on the height of the transformation derivation. The cases Skip, 
Setiou;, Set high, Wait and Signal follow from the reflexivity of A. The proof 
for Seq, While, Par, Fork and Itiow is by the induction hypotheses and the 
congruence of A. 

The remaining case is Ithigh (reasoning for li'high is analogous). We have 
if B then Ci else C2 ^ d B then C'^; SI2 else Sli,C'2 : skip; Sli; SI2. By in- 
duction, C( A Cl and C2 ^ C2. The side condition guarantees that there are 
no assignments or synchronisation in the slices Sli and SI2 of the branches Ci 
and C2. Thus, Sli and SI2 contain only (potentially nonterminating) dummy 
computation without changing the state. The insertion of such a computation 
might (infinitely) slow down the computation. By the definition of A, we have 
C'l, SI2 ^ Cl and Sh; C'2 ^ C2. The congruence of ^ yields C' < C. □ 

5 Secure Programming with Synchronisation 

Despite restrictions imposed by the security requirements, one can still write 
useful programs with synchronisation. This section gives a simple example of a 
secure program that uses synchronisation. 

Let us use split binary semaphores [ 5 | in an example implementation of sim- 
ple web-form processing. Suppose web forms are used for registering users of a 
security-sensitive website. As an entry gets processed, the low and high outputs 
are computed. In particular, the low variable counter is incremented. The high 
variable milcounter is incremented whenever the affiliation of the user is military. 
The program fragment is given in Figured 

The high variables are record, buf, result and milcounter. The low variables 
are counter and the semaphore variables empty and full. We assume a language 
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Main : C; fork(Di, D2) 

C : empty := 1; full 0; counter ~ 0; milcounter ~ 0 

Di : while True 

do ... /* produce a new record when a new form is submitted */ 
wait(empft/); 

buf -.= record', /* the record is now in the buffer */ 
signal(/wZ/) 

D 2 : while True 

do wait(/uf/); 

result buf; /* fetch the record */ 

signal(emptj/); 

if result.org — military 

then milcounter := milcounter + 1 

else skip 

counter := counter + 1; 



Fig. 9. Example of secure programming with synchronisation 
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Fig. 10. Approaches to security analysis of multi-threaded programs 



with enriched data structures (records) for the purpose of this example, but this 
does not affect the security argument. The program is accepted by the type 
system. Thus, the program is secure and, in particular, free of timing leaks. 



6 Conclusions and Related Work 

We have investigated the security of information flow in multi-threaded programs 
in the presence of synchronisation. The main result is that allowing neither syn- 
chronisation on high nor any synchronisation (not even on low) in the branches of 
an if-on-high is sufficient for building up a compositional timing-sensitive security 
specification from previous definitions that did not consider synchronisation. We 
have also proposed a type-based analysis that certifies programs according to the 
security specification. Let us conclude by discussing some improvements of this 
analysis compared to previous certification systems for security. Figure [TU] gives 
a comparative overview of some of the most related approaches to analysing con- 
fidentiality of multi-threaded programs. The first column Ref gives references 
to the related systems. NI means whether the system has been proved to certify 
secure programs under an extensional noninterference- like security property. The 
third and fifth systems have been proved to guarantee probabilistic noninterfer- 
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ence. We expect probabilistic noninterference to hold for the presented system 
(in fact, it has been designed with probabilistic noninterference in mind). Fu- 
ture work includes developing a soundness proof with respect to probabilistic 
noninterference . 

Dec stands for whether the system is given with a decision algorithm. All 
but the first system are decidable type systems whereas the first system is formu- 
lated as a logic with no decision algorithms or soundness proofs. Sync indicates 
whether the underlying language has synchronisation primitives. Only the first 
and the present investigations consider synchronisation. Furthermore, Agat [ 2 ] 
only considers sequential programs. 

Time says whether the system captures timing covert channels. Andrews 
and Reitman jl] sketch the possibility of taking into account timing leaks in 
their security logic. However, the proposed mechanism rejects all programs that 
branch on high variables. Heintze and Riecke m stress the importance of timing- 
style attacks in a concurrent setting but do not give a proof that the type system 
accepts programs free of such attacks. Volpano and Smith consider timing flows 
in |21| . They allow branching on high by requiring all if-on-high commands 
to be embraced by special protect commands. The protect executes atomically 
by definition, making the timing difference invisible for the attacker. Such a 
command seems difficult to implement without locking the execution of every 
atomic command in the language or, as suggested by Smith Hi , using additional 
mechanisms like thread priorities. Even that will not close external timing leaks, 
i.e., a time-consuming computation will not be hidden by a protect from the 
attacker with a stop-watch. 

Acknowledgements. Thanks are due to David Sands for fruitful discussions 
and to Johan Agat and Makoto Takeyama for many valuable comments. 
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Abstract. A priority discipline without time measurements is de- 
scribed. The universality of this discipline is proved. The application 
of this discipline for the performance of TCP is shown. 



1 Introduction 

In this paper we describe a dynamic (changing in time) priority discipline of a 
service system, which does not require time measurements. We prove that this 
service discipline has all possible queue mean lengths for a one-device service sys- 
tem with ordinary flows of primary customers and branching flows of secondary 
customers. 

The use of the discipline for organizing the work of the — (Transmission 
Control Protocol) |T| allows us to eliminate some TCP disadvantages, such as: 
the interpretation of a lost packet as the network overload, bulk transfer and so 
on. In this case, there is no need to make any changes in the TCP. 

There are some works (see, for example, |3], [2]) which improve the TCP. 
The works propose a modification “ with an adaptive rate” (ARTCP), 

which improves the TCP, but requires the introduction of an additional field to 
the protocol, namely, the round trip time interval. 



2 Theoretical Results 

In this section we describe a service discipline (the rule of selecting packets) 
without time measurements. We call it a probabilistic-divided service discipline. 
For the one-device service system with ordinary flows of primary customers and 
branching flows of secondary customers we show that this discipline has all 
possible queue mean lengths. 

2.1 Probabilistic-Divided Service Discipline 

Now we introduce a probabilistic-divided service discipline [S] . 

Let our system have n types of customers. The parameters of this discipline 
are 
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— a cortege oi N = 2n natural numbers a = (oi, 02 , , oat) such that 

Vi G {1,2, ...,n} 31 < /(i) < i(i) < TV : a/(i) = a,(i) = i; (1) 

— N real numbers b = (5i, . . . , 6 at) (0 < bi), such that 

^/(b 3" ~ ^ Vi G (1, 2, ... , n}. (2) 

Define the priority pi (1 < pi < N) of every new customer of the type i 
(1 < i < n) (arrival or appear after branching) as 

^ f /(i), with the probability &/(,); , . 

with the probability ' ' 

where f{i),l{i) are defined in[Tl 

For the service we select the customer with the least priority. 



2.2 Model 



The service system has proven to be a useful tool for system performance analy- 
sis. In this section we have extended the application of such a system by incorpo- 
rating populations of branching customers: whenever a customer completes the 
service, it is replaced by v customers, where v has a given branching distribution 

IS- 

This single-server system is defined as follows: 

— customers arrive according to a Poisson process with a rate A; 

~ a newly arriving customer receives a type i with probability f3i, {Pi > 0,/3i-|- 
. . . + Pn = 1); 

— the service is nonpreemptive; 

— the durations of service are independent random variables with the distribu- 
tion function Bi{t){Bi{0) = 0) for i-type customers; denote by 

poc poo 

bi= tdBi{t) < 00 , bi 2 = / t^dBi{t) < oo; (4) 

Jo Jo 

— whenever the i-type customer completes service, it is replaced by i^i cus- 
tomers, where Ui = {k\,k 2 , ■ ■ ■ ,kn) with probability qi{ki,k 2 , ■ ■ ■ ,kn)', by 
Qi{z) = Qi(zi, Z 2 , ■ ■ ■ Zn) denote a generating function of i^i and denote by 



Qij = 



dQi 

dzj 



(1,...,1) < oo. 



dzjdzk 



(1,...,1) < oo. 



( 5 ) 



(because of the applications being modelled, our interest is confined to a 
system in which a branching process Vi generates a total population with a 
finite expected size); 

— new customers are immediately feed back to the ends of the corresponding 
queues; 
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— if the queue is not empty, the server immediately selects (by the service 
discipline) a customer and running; 

— by 7 i we denote the expected total amount of service provided to a customer 
of type i and all its population; denote by 

P = A^/3i7i<l- (6) 

Let 

1 

Li = lim — / Ek{t)dt, 

T^oo 1 Jq 

where li{t) is the amount of f-type customers in the queue at a moment t (1 < 
i < n). 

Let Li(a, b) be the mean length of customers of type i with the probabilistic- 
divided service discipline. 

Our main theorem generalizes and improves the result of [H]. 

Theorem 1. Let be a mean length of queues under the stable 

regime with any service discipline, then there exist parameters a and b of the 
probabilistic- divided service discipline, such that Li(a,h) = L* , i = 1,2, . . . ,n. 



3 Proof of the Theorem 

To prove this theorem, we need some notation. 

Let Xi be the rate of type i customers (arrive or appear after branching). 
Then 



n. 



Xi — ^ ^ 'L XPi, i — 1 , 2 ,... 
i=i 

The proof is found in |3 . 

In paper [^, the second author has proved that 

Er=i-^i7i = w({l, 2 ,...,n}), 

E^esL*MS)>coiS), V5c{l,2,...,n}, 



(7) 



( 8 ) 



where 7 ^( 5 ”) is the expected total amount of service provided to a customer of 
type i € S and all its population in S ( 7 i({l, 2, . . . , n}) = 7 ^), and 

uj{S) = inf Li{a,b)-fi{S) . 

a,b 



i^S 



Without loss of generality it can be assumed that 
Ll/Xi < L*JX2 <...< L*JXn. 



(9) 



Under the conditions of the theorem and (0, we describe an algorithm for 
finding parameters a and b of the probabilistic-divided service discipline. 
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STEP 0. Let 

ai = 1; 

02 i = i + 1, 1 < i < n — 1] 

a 2 i+i = i, 1 < i < n - 1; 

Cl2n ~ '^5 

bo = (0, 0,1,0, 1,0,1, 0,1,0,. ..,0,1,1), 

and 

L° = Li(a,bo), i=l,2,...,n. 

By S denote a subset of {1, 2, . . . , n} such that 

S = {z:L^> L*}. 

STEP 1. Solving the system of equations 

L,{a,h) = {l-t)L° + tL*,i = l,2,...,n, 



( 10 ) 



with the complement condition 

if j G S' then bj = 1 else bj = 0, 
we get the solution (tj , d) for j = 2, 3, . . . , n. 

Let 

tn, = min |t,T. 

2 <j<n 

li t a = 1, we find parameters a and b of the probabilistic-divided service 
discipline. 

STEP 2. Let a € S (therefore da = 0). 

Let 

m = min{i : i > 1 (a), ai € S,ai > a, l(ai) = i}, 

k = maxji : i > m,ai ^ S,ai < a}. 

If the maximum is not defined, we set k = m. 

Displacing af(^a) = ck after Ofc, we get a new cortege 

a (ui, . . . , Clj^f^a) — ! 7 (a) -i-li ■ • ■ 7 )Cr,Ufc-|_i, . . . , CL 2 n) • 

Go to STEP 1. 

STEP 3. Let a ^ S (therefore da = 1)- 
Let 

m = max{f : i < f(a),ai € S, at < a, f(ai) = i}, 

k = min{i : i < m,ai ^ S,ai > a}. 

If the minimum is not defined, we set k = m. 

Displacing au^a) = ol before a^, we get a new cortege 

a (ct^ , • ■ ■ , ^k — 17 ^7 ^k7 ■ ■ • 7 ^l{a) — l7 ^l{a) + l7 ■ ■ ■ 7 ^2rt) ■ 

Go to STEP 1. 

The proof that such a new cortege always exists is found in [0] . 
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4 Modification of the TCP 

The main idea of the suggested TCP modification is the following: in the ARTCP 
(considered in [3j, [^) the round trip time interval is replaced by the length of 
the corresponding queue. 

The experimental testing of the ARTCP, carried out in the paper [S|, has 
shown its efficiency. At the same time we can apply theorem [T] which shows that 
on average our suggested modification of the TCP has the same possibilities as 
the ARTCP. Thus, our modification improves the TCP, but does not require the 
introduction of an additional field in the protocol. 

Let us consider our TCP modification. Without entering in details of the 
ARTCP (see [4], [5j) we shall describe its main characteristic feature, namely, 
the packet transmission rate. It is exactly the feature we will modify. Other 
components of the ARTCP will be without changing. 

Let us define the rate that is used in the ARTCP (see a, m- For every 
sent packet (in the Round Trip Time (RTT) interval) the ARTCP memorizes 
the value oi t = — to , where to is equal to the time of the current packet 

sending off and is equal to the time of the next packet sending off. The 

receiver memorizes the value of r in the corresponding field. Then the rate has 
the following value 

R = S/t, 

where S is the length of the corresponding packet. 

In the suggested modification the value r is replaced by the value h/Xi, where 
li is the length of the queue from the packet set of the given type i and Xi is 
defined in dZ). 

Instead of rate changing we change the corresponding parameter 6^. The 
increment of the parameter bi leads to the increment of the rate R. 

If bi = 0, then we change the parameters a, as described in STEP 2. The 
parameter b will be set up in its initial value. 

If bi = I, then we change the parameters a, as described in STEP 3. The 
parameter b will be set up in its initial value. 

5 Conclusion 

Thus, the described construction allows us to eliminate the measurement in the 
service system. The application of this result to the TCP simplifies the ARTCP 
and doesn’t require an additional field in the protocol. As a result, the use of 
probabilistic-divided discipline for organizing the work of the — eliminates some 
TCP disadvantages. 
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UML and similar modelling techniques are currently taking momentum as a 
de facto standard in the industrial practice of software development. As other 
Object Oriented modelling techniques, they have benefited from concepts in- 
troduced or explored in the field of Algebraic Development Techniques — for 
short ADT, formerly intended as Abstract Data Types — still an active area of 
research, as demonstrated by the CoFI project. However, undeniably, UML and 
ADT look dramatically different, even perhaps with a different rationale. We try 
to address a basic question: can we pick up and amalgamate the best of both? 
The answer turns out to be not straightforward. We analyze correlations, lessons 
and problems. Finally we provide suggestions for further mutual influence, at 
least in some directions. 
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Abstract. We use tuples of extended class, object and statechart UML- 
diagrams as UML specifications of real-time systems. The semantics of 
the UML specification is defined by transformation to the extended 
Timed Graphs (XTG). The correctness of our transformation is demon- 
strated by showing that the XTG computation tree can be projected 
into the computation tree of the corresponding UML specification. The 
transformation opens the possibility to specify temporal-logic properties 
at the UML level and to verify them at the XTG level using the PMC 
model checker. 



1 Introduction 

The Unified Modeling Language (UML) is the object modeling standard |T] that 
provides a set of diagrams for system specification from static and dynamic 
perspectives j^. Nowadays, it is becoming more and more custom for designers 
to use formal methods during the design. The formal methods allow to verify 
a system specification with respect to its property specification. The system 
specification in UML can be formalized jl], however, the property specification 
is limited by the logic of the Object Constraint Language (OCL) [B] which does 
not allow properties of computational paths, reachability, etc. to be specified [2]. 

This paper shows our approach to specification of systems and properties in 
UML. In section 2 we consider a tuple of UML class, object and statechart di- 
agrams as a new input language of the Prototype Model Checker (PMC) being 
under development in Delft University of technology |7]. PMC is intended to 
verify system specification with respect to properties represented in a variant of 
Time Computation Tree Logic (TCTL). However, the level of the original system 
specification language of PMC, namely Extended Timed Graphs (XTG), is too 
low for the specification purpose. The specification language of the acceptable 
level is UML. In section 3 we represent the transformation of the UML specifica- 
tion into XTG. In section 4 we conclude about the results of the transformation 
that allows to specify system properties by TCTL at the UML level and to verify 
them by means of the PMC. 
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2 System Specification. Property Specification 

1. We have chosen three kinds of UML diagrams to specify a system. 

- Class and object diagrams define a static view of the system. A class diagram 
specifies sets of classes Cls with their attributes Ats and operations Ops- An 
object diagram defines a current set of class instances. 

To enable the measurement of time we introduce clock attributes of special 
DenseTime type. A clock attribute can be reset to a nonnegative real value. 
After resetting the value of the clock attribute continuously increases. 

- A UML statechart diagram addresses a dynamic view of the system. All la- 
bels of the statechart use names that are defined by the UML class and object 
diagrams [3|. 

We define a UML statechart as a tuple SchD = (S, So, Rl), where 

- S' is a tree of states. The states are depicted in the statechart diagrams by 
boxes with round corners. There are states of three types in this tree: AND, 
XOR and Simple. AND and XOR nodes are hierarchical states. One of them 
is a root of the tree of states. Nodes Ai,...A„ of a hierarchical state C are 
drawn inside of C. An AND-state is divided by dotted lines to put other states 
between such lines. A simple state does not contain other states. In general, a 
state s is marked by {Names, History g, lus. Outs) labels. The labels Historps, 
I Us, Outs can be empty. 

- So C S is a, set of initial states. 

- Rl is a set of relations among states Rl — {TR, Conn, Synch}. 

- TR is a set of transitions that are represented by labeled arrows. 

TR= {{s^,sj,e,g,a)\si,sj G S; e G Ops, 

g G Boolean Expression{Ats, Ops), a G Ops}. 

- Conn = {{I,0)\I G1 S,0 C S,}. The relation is represented by a black 
rectangle (fork-join connector) and by arrows that are directed from 
each state li G I to the connector and from the connector to each 

state Oj G O. 

- Synch = {{I,0)\I C S,0 C S}. The relation is drawn by two black 
rectangles (fork and join connectors) and by a circle of a synch-state. 

A transition semantics of a UML-statechart, in general, was defined in |3] as 
a computational tree. A node of this tree is a vector n = {s,v,q), where s G S 
of the SchD, u is a tuple of values of all attributes of objects from the object 
diagram, q is a queue of operation calls from the SchD. 

2. To enable the specification of properties of computational sub-trees, we define 
specification classes. Specification classes are stereotyped. They can be related to 
a set of traditional classes. Each stereotype of specification has its own intuitive 
name and a formal representation by a parameterized TCTL formula [3]. The 
TCTL variant that we use m contains location predicates and reset quantifiers 
over variables. 
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3 Transformation Rnles 

We transform a tuple of UML class, object and statechart diagrams into XTG, 
the original language of the Prototype Model Checker. 



3.1 XTG 

XTG is a formalism for describing real-time systems. 

An XTG is a tuple G = (U, L, Iq,T), where 

- U is a finite set of variables of the following 

DataType = {Integer^ Enumeration, Real, DenseTime}. 

DenseTime is a type for representing clocks (as nonnegative real that increases 
continuously). 

- L is a finite set of locations (nodes). Iq G L is an initial location; 

- T is a finite set of transitions (arrows with labels). T — {(li,lj,c,up,ur)}, 
where li,lj G L, c G BooleanExpression{V), up G ValueAssignment of the 
variables V, ur G {U r gent, UnUr gent}. An urgent transition is represented by 
an arrow with a black dot. 

A state in the time computation tree semantics of the XTG is defined 0bya 
location and the values of variables in the location {I, p). A transition from a state 
(I, p) is enabled if c{p) = True after the substitution of the variable values. Time 
can pass in state as long as its invariant is satisfied and no urgent transitions 
are enabled. Time is not allowed to progress while a transition marked as urgent 
is enabled. The parallel composition of XTG is defined [7j by a synchronization 
mechanism that is based on a form of value passing CCS . A synchronization 
is a pair of labels specifying that the transition marked by syn\ in an XTG is 
executed simultaneously with a transition marked by synl in another XTG. 



3.2 Transformation Steps 

We make the transformation of the UML specification into XTG in three steps. 

— First, we represent the hierarchical states from the statecharts introducing 
the CCS synchronization. The result of this transformation we name the flat 
statecharts. A flat statechart is a UML statechart which does not contain hi- 
erarchical states and uses the CCS synchronization mechanism. The parallel 
composition of two flat statecharts is a flat statechart such that the set of 
its transitions is defined by rules of XTG parallel composition. 

— Second, we transform the flat statecharts defining the run to completion 
semantics of operation calls and semantics of signals using the synchroniza- 
tion. 

— The last step means the transformation of fork-join connectors and synch 
states of the flat statescharts to XTG. 
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Prom Hierarchical Statecharts to Flat Statecharts 

XOR state with the History mark. The transition to the XOR state (fig[Tl) means 
the transition to the initial state ai among substates oi, 02- The transition from 
the XOR state ci means the transition from the current state at. Only one 
substate from the a-set can be the current substate. The history label means 




Fig. 1 . XOR states 



memorizing of the current substate of the XOR state and starting the next 
computation inside of the XOR state from this substate. The semantics is shown 
by the computation tree (figHb). 

We represent the statechart (figdl) by two XTG: the external graph (cq, Ci, C2) 
and internal one (oi, 02). The history label means that there is a history state Hi 
for each a^. States cq, Hi are initial for the system. The transition to the XOR 
state is replaced by two synchronous transitions: (cq, ci, x!) and (Hi, ai, x?). The 
value of i depends on the last active state of the internal graph. The transition 
from the XOR state is replaced by pair of synchronous states (ci,C2,y!) and 
{ai,Hi,yl). 

AND state. The transition to the AND state C(fig[ 2 H) corresponds to transitions 
to both initial states of substatecharts of A and B. The arrow from AND state 
C means the transitions from the current states of A and B. The transition from 
each state of A, B is possible. The corresponding computation tree is shown in 
figOb- In the flat statechart representation there are three sub-graphs (fig. 12 }:). 
There is a projection of the computation tree (fig. [ 2 tl) of the flat statechart to 
the computation tree of the statechart (flgl2t>)- In this projection one transi- 
tion to AND state {M, X, Ai, Bi) — >■ {M,C, A\, B{) is modeled by two transi- 
tions in the computation tree of flat statechart {X,Aq,Bq) — >■ {Xi,Ai,Bq) — 
{C,Ai,Bi). A transition from AND state is modeled by a subtree: for exam- 
ple, (M, C, A2, B2) — t {M,Y,Ai,Bi) (fig. [2b) is represented by {C,A2,Bi) 
(yi,Ao,Ri) ^ {Y,Ao,Bo) and (C,A2,Ri) ^ (^1,^2, So) ^ (Y,Ao,Bo). AND 
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Statechart Flat statechart Computation tree 




Fig. 2. AND states 



state with the history label are transformed to flat statecharts using the combi- 
nation of rules given in two previous cases. 

Transformation of Operation Calls and Signals 



Flat statechart 



O ( A1 ) A2 ) 

-OpIsFinished 



Computation tree 



Computation tree 







_h 


atAl.Cl.yU) ^ tAU,CU,lj2) ^ lAU,L.2,y.tJ ^ tA2,C2,yU) 

d 



Fig. 3. Operation in statecharts 



Let an operation op be called by the object A and be fulfilled by the object 
C (flgHJr). If the operation call is shown in UML statechart, it means that 
the operation will run to completion. The corresponding computation tree is 
represented in the flgEt>- The operation call of the object A is shown by the 
label opa. The time between the operation call and the operation end [H| is the 
subject of the specification in real-time systems and it can be shown by updates 
of clock attributes at the moment of the operation call. When an operation is 
called by several classes then there is a time between the operation call and 
the moment of the begin of the operation. To represent the semantics of the 
operation calls we extend graphs of objects A,C by states Aq,Co and use an 
additional flat statechart Q with four states to model each operation call (fig®.) 
The internal state of this graph Qi allows to wait for the moment of the begin 
of the operation. This moment is shown by synchronization s with the graph C. 
When the operation has been fulfilled, graph Q is synchronized by endopA with 
graph A. The computation tree of the flat statechart is shown in flg®l. There is a 
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projection of this tree to the computation tree of the statechart: three transitions 
{Ao,Ci,Qi) -)> (^o,C'o,Q 2 ) -?■ {Ao,C2,Q3) {A 2 ,C 2 -Qo) in the computation 

tree of the flat statechart correspond to one transition (Ai,Ci,opa) — >■ (Ai, C 2 ) 
in the computation tree of the statechart. 



Statechart 



Computation tree 




Fig. 4. Signal in statecharts 



Let a signal be sent to two objects flgHJi. The moment of sending is a subject 
of specification in real time systems. The reactions to the signal can come in 
different moments. To represent the behaviour of a signal by flat statecharts 
(flglUb) we extend the set of states to fix the moment of the signal sending and 
to send 2 synchronizations Sig\. We can see in flg|lh,d that the computation 
tree of the flat statecharts and the computation tree of the statechart are equal. 



Transformation of Flat Statecharts 

Assume now that all XOR, AND states, operation calls and signals have been 
transformed and a flat statechart has represented a system specification. 

In flgl^ there is a statechart with a fork-join connector and its XTG repre- 
sentation. The semantics of the join-fork statechart is the following. First, all 



Statechart , X I'G 
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Fig. 5. Fork-Join connector 



transitions to the connector have to be finished. The order of the transitions 
is nondeterministic. When all transitions to connector have been finished then 
the transitions from the connector are enabled. The order of the transitions is 
nondeterministic . 
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Statechart 





Fig. 6. Synch state 



Synch state. The graph that is defined by means of S'ynch-relation is a stat- 
echart fig. 0 The semantics of this statechart uses the semantics of connectors 
and the synch state. The last one guarantees that one region of statechart leaves 
a particular state before another region can enter a particular state. If a synch 
state is marked by number 1 then one input to synch state corresponds to one 
output from it. This case is shown in the fig. |6] If a synch is marked by number n 
then one input to synch-state can correspond to n outputs from it. An unlimited 
synch-state is marked by symbol *. 

In and Out labels of the state mean that all edges to the state are marked 
by In and all edges from the state are marked by Out. 

4 Conclusion 

Analyzing the transformation rules of our UML specification into the input lan- 
guage XTG of the PMC toolset we can conclude that there is a projection of 
the XTG computation tree into the computation tree of the corresponding UML 
specification. So, the properties of computational sub-trees specified at the UML 
level are visible at the XTG level. The TCTL variant that we use m contains 
state predicates and reset quantifiers over clocks. For example, we would like to 
specify a Deadline for the state y for the statechart with an AND-state (fig.[3), 
i.e. if we are situated in state x of the class X we should achieve state y till the 
deadline T. The stereotype Deadline has the clock attribute t , the parameters: 
deadline T, two state predicates X@a; , X@y and the following TCTL formula: 
AG{X@x => {t := 0).{AF{X@y A t < T))). 

The PMC tool is able to verify temporal properties of systems with unlim- 
ited sets of traces. The combination of the model checker power and the UML 
specification power allows to apply formal methods into every day practice of 
design. 
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Abstract. The paper aims at establishing the semantical background 
for extending Petri net formalisms with an object-oriented approach by 
bringing together Nested Petri Nets (NP-nets) of Lomazova and Linear 
Logic Petri nets (LLPNs) of Farwer. An introductory example shows 
the capabilities of these formalisms and motivates the proposed inter- 
encoding of two-level NP-nets and LLPNs. A conservative extension to 
the Linear Logic calculus of Girard is proposed - Distributed Linear 
Logic. This extension of Linear Logic gives a natural semantical back- 
ground for multi-level arbitrary token nets. 



1 Introduction 

Modularisation and the object-oriented programming paradigm have proved to 
be facultative for the development of large-scale systems, for instance in flexi- 
ble manufacturing, telecommunications, and workflow systems. These efficient 
approaches to systems engineering stimulated researchers in the Petri net com- 
munity to develop new flavours of Petri nets, such as LOOPN of C. Lakos [6] and 
OPN of R. Valk [TO], which incorporate object-oriented aspects into Petri net 
models (see also the survey El , referring to a large collection of techniques and 
tools for combining Petri nets and object-oriented concepts). The design of these 
new net formalisms has led to the problem that only very few results from the 
traditional theory of Petri nets are preserved and thus the spirit of the Petri net 
model is altered considerably. Moreover, many of the object-oriented extensions 
of Petri nets are made ad hoc and lack a formal theoretical background. 

The formalisms studied in the present paper take a more systematic view 
of objects in Petri nets in order to allow the application of standard Petri net 
techniques, and hence they do not follow the object-orientation known from 
programming languages in every aspect. Their study aims to give some insight 
into how objects can be integrated into Petri nets in a way that does not violate 
the formal basis of the initial model. 

* This research was partly supported by the Russian Foundation for Basic Research, 
Project No. 99-01-00309 
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We consider two independently proposed extensions of ordinary Petri net 
formalisms, both of which utilise tokens representing dynamic objects. The idea 
of supplying net tokens with their own net structure and behaviour is due to R. 
Valk HO). 

In Nested Petri nets (NP-nets) [Zj tokens themselves are allowed to be nets. In 
contrast to Object Petri nets of Valk, where an object net token may be in some 
sense distributed over a system net, in NP-nets a net token is located in one place 
(w.r.t. a given marking). This property facilitates defining formal semantics for 
NP-nets and makes possible a natural generalisation of this model to multi-level 
and even recursive cases [H|. The main motivation for introducing NP-nets was 
to define an object-oriented extension of Petri nets, which would have a clear and 
rigorous semantics, but still be weaker than Turing machines and maintain such 
merits of Petri net models as decidability of some crucial verification problems. 
It was stated in [U] , that while reachability and boundedness are undecidable for 
NP-nets, some other important problems, namely termination and coverability, 
remain decidable. 

Linear Logic Petri nets (LLPNs) have been introduced as a means for giving 
purely logical semantics to object-based Petri net formalisms. The basic property 
that makes Linear Logic, introduced in 1989 by Girard [5j, especially well-suited 
for this task is the resource sensitivity of this logic . The nature of Linear Logic 
predestines it also for the specification of Petri nets with dynamic structure [ 2 ] • 
A Linear Logic Petri net is a high-level Petri net that has Linear logic formulae 
as its tokens. The token formulae can be restricted to a fragment of Linear Logic 
to maintain decidability. Arcs have multisets of variables as inscriptions and the 
transitions are guarded by sets of Linear Logic sequents that are required to be 
derivable in the applicable sequent calculus for the transition to occur. Then 
in [ 2 ] it was shown, that two-level NP-nets also allow a natural Linear Logic 
representation, and thus have a very close relation to LLPNs. 

Linear Logic of Girard has proved to be a natural semantic framework for 
ordinary Petri nets, such that the reachability of a certain marking in the net 
corresponds to the derivability of the associated sequent formula in a fragment 
ILLpN of the intuitionistic Linear Logic sequent calculus. In this paper we pro- 
pose an extension of Linear Logic to Distributed Linear Logic, which allows, in 
particular, giving Linear Logic semantics to multi-level object nets. The main 
difference from classical Linear Logic will be in that resources, represented by 
formulae, will be distributed (belong to some owners or be distributed in space), 
so that two resources located in different places (or belonging to different own- 
ers), generally speaking, cannot be used together. To express this we propose the 
use of the special binary operation P (“possesses”). We write A{cj)) for P{A,(j)), 
where A is an atomic symbol, representing an owner or location, and (/> is a 
Linear Logic formula (possibly including the “possesses” operation). 

There is a natural interpretation of the “possesses” operation, which contin- 
ues Girard’s example from about possessing a dollar and buying a box of 
cigarettes. Let D he a, dollar and C be a pack of cigarettes. Then A{D) desig- 
nates that person A owns a dollar; A{l{D^C)) means, that A has an ability 



A Systematic Approach towards Object-Based Petri Net Formalisms 



257 



to obtain cigarettes for a dollar (e.g. A is not a child). Further in this setting 
A(D) — o B(D) means that A can pass his dollar to B, and A{x) — o B{x) (implic- 
itly universally quantified for x) means that A is ready to give B everything he 
or she owns. 

The paper is organised as follows. Section [2] gives a brief introduction to the 
main Linear Logic connectives leading to the encodings of traditional Petri nets, 
coloured Petri nets (Section |3| and to the definition of Linear Logic Petri nets. 
Section E] contains an example of modelling by NP-nets and LLPNs, showing 
some connections between the two formalisms. Section O is devoted to a formal 
translation of NP-nets into LLPNs and vice versa and contains results presented 
in [3|. Here the NP-nets are assumed to have only bounded element nets. In 
Section El we introduce an extension of Linear Logic by the “possesses” operator 
and use it for the Linear Logic representation of multi-level NP-nets. Section H 
gives some concluding remarks. 



2 Linear Logic Encoding of Petri Nets 

Girard’s Linear Logic [S| differs from classical logic in that the structural rules of 
weakening and contraction in a Gentzen-style sequent calculus are restricted to 
special versions where the main formulae are in the scope of a special modality 
called of course, which is needed to retain the expressiveness of classical logic. 
This modality is used to make a formula reusable - a typical classical property, 
which is also of utmost importance for the modelling of Petri net transitions. 

Every formula is treated a a resource in Linear Logic. Thus, a derivation 
using an implication and its premises actually consumes these and produces 
the respective consequences in the form of new instances of resources of an 
appropriate type. 

The lack of structural rules results in two fragments of Linear Logic, called 
the multiplicative and additive fragment. Each fragment has its own kind of 
conjunction and disjunction. The most interesting fragment for the encoding of 
Petri nets is the multiplicative fragment, because it is resource sensitive. The 
additive fragment behaves essentially like in classical logic and is less interesting 
for our goal. 

The multiplicative conjunction (®, tensor or times) is used to accumulate 
resources. It is essential to understand that unlike in the case of the classical 
conjunction where A A A = A, this equation does not hold for the multiplicative 
conjunction, i.e. A^ A ^ A. 

The behaviour of a Petri net is determined by the consumption and produc- 
tion of tokens when firing transitions. Modelling this as a Linear Logic formula, 
one has to remember that a linear implication is also treated as a resource un- 
less it is preceded by the modality of course. A transition with input places A 
and B, output places B and C and an arc weight of one on all arcs except the 
input arc from A, which has weight two (see Figure [T]), can be represented by 
\{A^ A^ B ^ B ^ C). The use of the modality is essential, because without it 
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the implication could be used only once in a derivation, but the transition can 
actually fire each time its input places contain sufficiently many tokens. 




Fig. 1. A Petri net transition 



For example, 

A^A^B^\{A^A^B^B^C) h B ® C®\{A® A® B ^ B ® C) 
is provable, but 

A®A®B®{A®A®B^B®C) h B®C®{A®A®B^B®C) 

is not, since the implicational subformula would have to be consumed in the 
derivation. 

Remark 1. In this paper we assume that the modality ! has stronger binding 
preference than the conjunction, which in turn has stronger binding preference 
than the implication. We use this rule of preference to keep low the amount of 
parentheses in formulae, making them more readable. 



3 Modelling Coloured Petri Nets by Linear Logic 

In this section we give a Linear Logic representation of Coloured Petri nets with 
a finite set of colours, a finite set of atomic individual tokens of different colours, 
and without guards. We extend the language L(ILLpn) of the intuitionistic 
Linear Logic to the language L(DILLpn) by adding the binary operation P (for 
possesses) in the following way. 

On the syntactical level we have: 

— a finite set of atom symbols A,B,. . . (corresponding to places); 

— a finite set of atom symbols a,b, . . . (corresponding to token colours); 
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— variables x,y, . . 

— the binary logical operations 0, — o ; 

— the modality “of course” !; 

— the binary operation symbol P (for possess). 

Formulae (terms) are defined as follows: 

— token atoms a,b, . . . and variables x,y, . . . are terms; 

— if A is a place atom, ip — a term, then P{A, (f>) is a term. We write A{(p) as 
a shorthand for P{A, (p); 

— if (p and ip are terms, then <p ® ip, (p —oip and !</> are terms. 

As usual for sequent calculi we define a sequent formula as an expression of 
the form F h </), where F is a sequence of terms and ^ is a term. 

Variables are interpreted as terms. The DILLpN calculus is obtained by 
adding to ILLpn the following rule for substituting a term for a variable: 

P \~ <P 

P[lp/x] h (pH’/^] 

Definition 1 (canonical formula for CPN). The extended canonical for- 
mula of a coloured Petri net M = {P,T, F,C,C,G,V,mo) is defined by the 
tensor product of the following factors. W.l.o.g., assume that each arc is carry- 
ing either a variable, or a constant ( then arc expressions of the form x-\-2y can 
he represented by multiple arcs): 

— For each transition t G T construct the factor 

■ p{W0{p,t))^ q{W0{t,q)) \ , 

\p€’t qef ) 

— Construct for the current marking m and all places p G P and tokens a with 
a G m(p) the formulae p{a). Thus, for the complete marking we get 

<S) 

p^p 

a£m{p) 

where multiple occurrences of tokens contribute to multiple occurrences of 
factors in the tensor product. 

Thus, for example, the formula 

!(A(a;) 0 B{y) -o C{x) 0 C{x)) 

corresponds to the transition shown in Figure 

It can be shown that the canonical formula en ( {Af, m) ) for a marked 

CPN {Af, m) is constructed in such a way that 

is derivable iff the marking m' is reachable in the marked net {Af, m) . 
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Fig. 2. A coloured Petri net transition 

4 Object-Based Modelling with NP-Nets and LLPNs 

In this section we discuss the encoding of net tokens, i.e. tokens in object Petri 
nets, that are themselves Petri nets. As before, in the Linear Logic encoding of 
a current marking, a separate factor of the form P{4‘)-> where 4> is an encoding 
of the corresponding net token, will represent a token occurrence in the place 
P. If there were no synchronisation, we would encode transitions as before and 
only add to DILLpn the following rule for representing autonomous behaviour 
of net tokens: 

F \- G 
A{F) h A{G) 

To deal with horizontal and vertical synchronization, as they appear in NP- 
nets, we have to employ a more subtle transition encoding, which will be intro- 
duced after some remarks on nested Petri nets in general. 




Fig. 3. Example of NP-net 



In NP-nets tokens are nets. A behaviour of a NP-net includes three kinds of 
steps. An autonomous step is a step in a net in some level, which may “move”, 
“generate”, or “remove” its elements (tokens), but does not change their inner 
states. Thus, in autonomous steps an inner structure of tokens is not taken into 
account. There are also two kinds of synchronisation steps. Horizontal synchro- 
nisation means simultaneous firing of two element nets, located in the same place 
of a system net. Vertical synchronisation means simultaneous firing of a system 
net together with its elements “involved” in this firing. Formal definitions of 
NP-nets can be found in mu. 



A Systematic Approach towards Object-Based Petri Net Formalisms 



261 



Figure [3] shows an example of a NP-net, where a system net has two places 
R and S and one transition marked by fill. In the initial marking it has one 
element net (with two places e and / and two transitions marked by fill and 
empty) in R. Here only a vertical synchronisation step via synchronisation label 
fill is possible. It moves the element net token to S and simultaneously changes 
its inner marking to /. 

An equivalent Linear Logic Petri net is shown in Figured 




Fig. 4. LLPN equivalent to the NP-net from Figure |3] 




Linear Logic Petri nets (LLPNs) are high-level Petri nets that have Lin- 
ear Logic formulae as tokens. Arcs are inscribed by multisets of variables and 
transitions are guarded by guard sets of Linear Logic sequents that include the 
neighbouring arc variables. A transition is enabled if there are sufficient token 
formulae in the respective input places and an appropriate binding, such that 
all guard sequents of one guard set are derivable in the underlying calculus. The 
formulae bound to the input variables are removed from their respective places 
and new formulae are placed on the output places according to the binding, the 
derivation, and the output arc inscriptions. 

Autonomous actions can take place in two different ways: Firstly, the envi- 
ronment net can have transitions that do not force the token formulae residing 
in its input places to undergo any derivation upon firing the transition. In this 
case the effect of firing the transition can be described as simply redistributing 
some token formulae without changing them. Secondly, the token formulae may 
evolve at any time according to the derivation rules of the underlying calculus, 
but remaining in the same place of the net, i.e. a formula a residing in some 
place may evolve to some other formula /? without the occurrence of any tran- 
sition in the Petri net, provided a h /3 is provable in the underlying calculus. 
These two kinds of autonomous action correspond to the autonomous firing of an 
environment net transition (transport) and the autonomous firing of an element 
net transition in a nested Petri net. 

The token formulae of a Linear Logic Petri net can be used to encode the el- 
ement nets of nested Petri nets. In the following sections we develop an encoding 
of nested Petri nets a formulae, such that a Linear Logic formula represents a 
complete nested Petri net, thereby establishing the foundation for a simulation 
of multi-level nested Petri nets by Linear Logic Petri nets. Modelling horizon- 
tal and vertical synchronisation is achieved by using synchronisation tags, i.e. 
propositional symbols that restrict possible derivations of the token formulae 
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and enforce the synchronisation between some derivation steps with the firing of 
a transition in the environment net. 

The reader is referred to |1I4| for an introduction to LLPNs. A discussion 
of further issues, especially dealing with dynamic modifications of object net 
structures can be found in |^. 

5 Inter-representability of Two-Level NP-Nets and 
LLPNs 

This section gives a brief sketch of a formal translation of two-level NP-nets into 
LLPNs and vice versa. It contains results presented in and restricts the class 
of NP-nets to those that have only bounded element nets. For a translation of 
multi-level NP-nets refer to the extension of the Linear Logic calculus proposed 
in section E] 

The main issue of any translation of an object Petri net formalism into a 
LLPN framework is how to deal with synchronisation. Instead of giving the 
complete translation of a given NP-net into its corresponding LLPN (which can 
be found in i), we sketch the main idea of synchronisation within LLPNs. The 
formal translation then follows as an obvious consequence. 

For each pair of system and element net transitions ts and te with adjacent 
vertical synchronisation labels £ and £ we define two new unique propositional 
symbols with the same name as the labels. W.l.o.g. assume these labels to be 
disjoint with any place names used in either net. We call the pair of labels 
message handles or synchronisation labels for the synchronisation of tg and te- 

Let, for example, \{A—oB) be a partial canonical formula of an element net 
-hf residing in place p of a Linear Logic Petri net CCPAf. The synchronisation of 
the system net transition tg with a transition tg in the element net via message 
handles {l,£) is represented by the token formula 

\{l® A^£® B) 

and by a transition in CCVAf with the guard function 

G{t) = {£'^x h 

Here the message handles are used to ensure that the derivation step, which 
takes place during the firing of the system net transition of the LLPN, really 
uses the Linear Logic implication representing the element net transition te- 

Thus, a synchronisation of a firing in the system net with the derivation step 
outlined above coincides with the vertical synchronisation step of the simulated 
NP-net. Horizontal synchronisation can be simulated analogously. 

The simulation relies on the boundedness of the NP-net, since it uses a propo- 
sitional calculus for the encoding. A generalisation of the calculus to overcome 
this restriction is discussed in the remainder of the paper. 

Theorem 1. For every unary elementary NP-net NPN without constants in arc 
inscriptions, there exists a canonical Linear Logic Petri net CCPAf npn , such 
that 



A Systematic Approach towards Object-Based Petri Net Formalisms 



263 



— the token formula in LCPM npn is the eanonical representation of the ele- 
ment net of NPN, 

— there is a bijection between the transitions of NPN and CCVM npn , which 
generates the bijection between occurrence sequences of the system net in 
NPN and occurrence sequences of LCPM npn ■ 

On the contrary, the simulation of LLPNs by NP-nets is possible only for 
a fairly restricted class of LLPN, since the definition of LLPNs is much more 
general. It allows variables to occur multiply in input and output arc inscriptions 
and the use of transition guards. gives some conditions for the possibility of 
a NP-net simulation for LLPNs. 

6 Extending the Linear Logic Calculus 

Linear Logic of Girard due to its resource sensitivity has a close resemblance to 
Petri nets: it has connectives that can handle resources in the same manner as 
ordinary Petri nets do. A Linear Logic representation of high-level Petri nets, 
such as e.g. coloured Petri nets of K. Jensen, can be achieved by simulating the 
“unfolding” of places and transitions (cf. E), when for each token colour a new 
copy of the place is created (technically, the set of places indexed by the possible 
colours represents the new set of propositional atom symbols for the encoding) . 

To obtain a straightforward Linear Logic encoding of high-level Petri nets the 
intuitionistic Linear Logic calculus ILLpn, used so far to encode Petri nets, can 
be extended from propositional to predicate level. Now formulae may contain 
variables, and all variables are supposed to be universally quantified. Then we 
introduce a special possess operation P for encoding that a place A contains a 
token X. Note, that components of NP-nets are high-level nets with net tokens, 
so the formula of the form P(A, <j>) will designate, that a net token with encoding 
(j) belongs to the place A. 

More formally, we extend the language L(ILLpn) of intuitionistic Linear 
Logic to the language L(DILLpn) by adding the binary operation P{-,-) C 
A X L(DILLpn), where M is a set of atomic symbols, representing owners or 
locations, in the way described in the previous section for coloured Petri nets. 

Now we can define the Linear Logic encoding of a NP-net by its canonical 
formula. Here, in the Linear Logic encoding of a current marking a separate 
factor of the form A((/)), where (j is an encoding of the corresponding net token, 
will represent a token occurrence in the place A. Analogously to the LLPN rep- 
resentation of NP-nets, given in the previous section, new propositional symbols 
with the same names as labels are used for encoding horizontal and vertical syn- 
chronisations. The approach taken here is completely symmetrical in the sense 
that each encoded net is provided with the facilities to participate in a horizon- 
tal synchronisation, or in a vertical synchronisation in either of the two possible 
parts, i.e. it can synchronise with a net on a lower or upper level. 

Remark 2. Note, that we have to take precautions to keep the sets of variable 
names used in different net token instances involved in a synchronisation step 
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disjoint in order to avoid ambiguities. In the following, we use W^^p^t) and 
W 0 (t,p) to denote the tensor product ^S>x&w{p,t}Pi^) ^x&wip.t)Pi^) 
spectively. W.l.o.g. we assume all variables used in arc inscriptions form a set V, 
such that for all a: G V we have x ^V. Then, by W^{p, t) we denote the product 
^xew{p,t)P(^) (analogously for W(g,{t,p)) . 

A nested Petri net consists of the following components: Af = {A/q, • ■ • , A/fc} 
is a finite set of net components, such that all place and transition names of net 
components in A/” are pairwise disjoint; Aq is a finite set of atomic tokens; I is an 
interpretation of constants in Af over A^ and A„(A/’, Aa); Ap is a distinguished 
net component, called the system net, m is a feasible marking of the system net 
Afo over Af and A^, called initial marking of a NP-net {P, T, W, m). 

Note also, that the definition of NP-net has some strict conditions on the use 
of variables for arc inscriptions: No variable may occur more than once on any 
input arc, and a variable occurring on one input arc may not occur on another 
input arc of the same transition. All variables occurring on output arcs of a 
transition must also occur on an input arc, i.e. the variables on output arcs of a 
transition are a subset of the variables from it’s input arcs. 

To each horizontal or vertical synchronisation label £ there exists an adjacent 
label £ that is needed in an appropriate marking for a synchronous synchronisa- 
tion step to occur. By definition we have £ := £. 

The previous remarks are important for an understanding of the definition 
of canonical formula given below. Variables named P, Px, a, ax, ■ ■ ■ are assumed 
to be new - otherwise unused - variables. The subterms P, Px, and P' are 
used as variables for the remainder of any nets that interact in some kind of 
synchronisation, i.e. the part of the net description that is left untouched by firing 
the transitions involved simultaneously. For example, in the NP-net of Figure |3] 
only the token net transition marked with the label fill can synchronise with the 
system net transition marked fill. Thus, for the encoding only these parts of the 
net structure are important for the synchronisation. The remainder (in this case 
the transition marked empty) must not be altered in the synchronisation step. In 
the simulating derivation this is accomplished by assigning the remainder to the 
variable P, which is passed through to the consequence of the linear implication. 
Hence, the resource is not used and is untouched by the derivation just like the 
remainder of the net. 

Definition 2 (canonical formnla for NP-net). The extended canonical for- 
mula of a NP-net {Af,Aa,T,Afo,m)is defined by the tensor product of the fol- 
lowing factors. W.l.o.g., assume that each arc is inscribed with either a variable 
or a constant, and let P denote the union of all place sets, T the union of all 
transition sets, and L the union of all label sets. 

— For each autonomous transition t G T construct the factor 
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— For each transition t £ T with a vertical synchronisation label i such that 
\/p £ *t ,W{p,t) ^ TN holds (i.e. all input places on the next lower level must 
hold net tokens), construct the factor 



p{r,c ® aa;(g)!(i' ® a^)) 



i pG *t x^W(p,t) 



qet’ x£W(t,p) 



q{Fs, ® a'^(g)!(£ ®ax^(-® a^)) 



(2) 



— For each transition t £ T with horizontal synchronisation label i £ L, con- 
struct the factor 



(^! [p{i{i, t)‘S> F) (g) p{l{£, t') ® F') ^ 

pGP 

p{i{£,t) ® F) ® p{L{l,t') ® F')\ (3) 

where 

i.{i,t) :=!(£g) 0 p{W 0 {p,t)) 0 q{W,^{t,q))) 

pG't qef 

— Construct for the current (initial) marking m and all places p £ P and 
tokens b with b £ m(p) the formulae p{W-£,'iu^-p-^{b)) . Hence, for the complete 
marking we have 



p(tf'DILLpN(&)), (4) 

pGP 

bGm(p) 

where multiple occurrences of tokens contribute to multiple occurrences of 
factors in the tensor product and in the special case of b being a black token 
S'dilLpn(^) := For some place p marked by a black token, p{») is usually 
abbreviated by p. 

The canonical formula of the NP-net is unique up to isomorphism (commu- 
tativity of the tensor product) . 

Thus, for example, the NP-net shown in Figure[2]is translated into the canon- 
ical formula composed of the following factors: 

From d2]): 

R{Fx ® o:a;(g)!(fill ® ax ^fill 0 a^)) —oS{Fj, 0 a(,0!(fill 0 ax — ofill 0 a^)) 
From (UJ: 



i?(e0!(fill 0 e —ofill 0 /)0l (empty 0 / -o empty 0 e)) 
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m and dD do not contribute to the canonical formula, since there are neither 
horizontal synchronisation labels nor autonomous transitions in the example net. 

In the example above we did not need factors corresponding to vertical syn- 
chronisation of element tokens with inner ones, since the net is only a two-level 
net. NP-nets provide means for communication with inner and outer nets, i.e. 
with nets on both upper and lower levels, whereas the canonical formula provides 
means for communication only with lower nets. Since there are always two nets 
involved in a synchronisation, both views are equivalent. 

Theorem 2. The sequent 

S'dillpn((A/", m)) h >?'dillpn((A/', m')), 

where !?e)ILLpn((A/', m)) is the eanonical formula for a marked NP-net (Af, m), 
is derivable in DILLpN iff m' is reachable from {Af, m) . 

Proof (sketch). For a canonical formula of an NP-net, synchronisation la- 
bels can occur only within the scope of some 1-modality. The same holds for 
implications. For this reason we can disregard all derivations where instances 
a of some subformula la from the canonical representation occur in either the 
antecedent or the succedent of any sequent. 

For the remaining sequents it is obvious from the encoding - if rather tedious 
to show explicitly - that the sequent from Theorem Elis provable if the respective 
markings are in the reachability relation for NP-nets. The converse is also true 
by an argument using the remark given above. □ 

7 Conclusion 

The main focus of our work on object-oriented extensions of Petri nets has 
been to establish core formalisms that have a clear mathematical semantics and 
preserve some important decidability results (see |7l8J l that are lost by many 
ad hoc extensions of the basic Petri net formalism. The independent definition 
of the two similar formalisms of Linear Logic Petri nets and nested Petri nets 
suggest that the foundations of these formalisms are sound and have a strong 
theoretical background. 

On the other hand, extending Linear Logic to deal with multi-level nested 
Petri nets leads to the logical framework, which has a natural interpretation not 
only for Petri nets, but for many applications, where a possibility of using these 
or other resources depends on their owners and/or locations. 
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Abstract. In this paper the unfolding technique is applied to coloured 
Petri nets (CPN) |6I7| . The technique is formally described, the definition 
of a branching process of CPN is given. The existence of the maximal 
branching process and the important properties of CPN’s unfoldings are 
proven. A new approach consisting in combining unfolding technique 
with symmetry and equivalence specifications U is presented and the 
important properties of obtained unfoldings are proven. We require CPN 
to be finite, n-safe and containing only finite sets of colours. 



1 Introduction 

The state space exploring in Petri net (PN) analysis is one of the most impor- 
tant approaches. Unfortunately, it faces the state explosion problem. Among the 
approaches which are used to avoid this problem are the stubborn set method, 
symbolic binary decision diagrams (BDD), methods based on partial orders, 
methods using symmetry and equivalence properties of the state space, etc. [M]. 

In [T^ McMillan has proposed an unfolding technique for PN analysis. In 
his works, instead of the reachability graph, a finite prefix of maximal branch- 
ing process, large enough to describe a system, has been considered. The size 
of unfolding is exponential in the general case and there are few works which 
improve in some way the unfolding definitions and the algorithms of unfolding 
construction ||5|8| . 

Initially McMillan has proposed his method for the reachability and deadlock 
analysis (which has also been improved in the later work [1 1|). J. Esparza has 
proposed a model-checking approach to unfolding of 1-safe systems analysis [S] . 
In jl] the unfolding technique has been applied to timed PN. In j2)4j LTL-based 
model-checking on PN’s unfolding has been developed. Unfolding of coloured 
Petri nets has been considered in the general case in m for using it in the 
dependence analysis needed by the Stubborn Set method. 

In the present paper the application of the unfolding method based on later 
works for ordinary PNs to coloured Petri nets (CPN) |6I7J is given. This allows to 
construct the finite unfolding for CPN and apply the reachability and deadlock 
analysis methods for it. It is allows to consider applying the model-checking 
technique to unfoldings of CPN, as well. The technique is formally described, 
the definition of a branching process of CPN is given. The existence of the 
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maximal branching process and the important properties of CPN’s unfoldings 
are proven. 

In |7] symmetry and equivalence specifications for CPN are introduced. In 
the present paper it is also presented a new approach consisting in combining 
unfolding technique with symmetry and equivalence specifications. This allows 
to reduce additionally the size of CPN’s unfolding. 



2 Coloured Petri Nets 

In this section we briefly remind the basic definitions related to coloured Petri 
nets and describe the subclass of colours we will use in the paper. More detailed 
description of CPN can be found in [B] . 

A multi-set is a function m: S^N, where S' is a usual set and N is the 
set of natural numbers. In the natural way we can define operations such as 
mi +7712, n-m, mi— m 2 , and relations mi <m 2 , mi<m 2 . Also |m| can be defined 
as \m\ = Var{E) define the set of variables of the expression E, 

and Type{E) define the type of the expression E. 

A coloured Petri net ( CPN) is the net N = (S, P, T, A, N, C, G, A, I), where 
S,P,T,A are the sets of colours, places, transitions, and arcs such that PDT = 
P(lA = TCA = 0, iV is a mapping N : A ^ {PxT)Ll{TxP), C is a colour 
function C : P^S, G is a guard function such that for all t£T Type{G{t)) = bool 
and Type{Var{G{t)))CS, E is the function defined on arcs with Type{E{a)) = 
G{p)ms, where p is the place from N{a) and Type{Var{E{a)))CS and I is the 
initial function defined on places, such that for all pGP Type{I{p)) = G{p)ms- 

A{t),Var{t),A{x,y),E{x,y) can be defined in the natural way. 

A binding 5 is a function from Var(t) such that b{v)GType{v) and G{t){b). 
The set of bindings for t will be denoted by B(t). A token element is a pair 
(p, c) where pGP and cSG(p). The set of all token elements is denoted by TE. 
A binding element is a pair (t,b) where tsT and bGB(t). The set of all binding 
elements is denoted by BE. A marking M is a multi-set over TE. A step Y 
is a multi-set over BE. A step Y is enabled in the marking M if for all p€P 
S(t b)eY ^ marking Mi is given by Mi{p) = M{p) — 

E{p, t)\b) + E(t,b)GV E{t,p){b). 

Now we can define a subclass of coloured Petri nets, which is large enough 
to describe many interesting systems and still allows us to build a finite prefix 
of its branching process. The detailed description can be found in [2]. The set 
of basic colour domains is obtained from the types of Standard ML (SML) jH] 
by allowing to consider only finite colour domains s£S. All functions defined 
in [B] and having the above described classes as their domains are allowed in 
our subclass. The CPN satisfying all the above-mentioned requirements is called 
S-finite. 

The marking M of a CPN is n-safe if |M(p)|<n for all pGP. A CPN is called 
n-safe if all of its reachable markings are n-safe. 1-safe net is also called safe. 
A preset of an element xGPUT denoted by *x is the set *x = {yGPUT \ 3a : 
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N{a) = (y,x)}. A postset of x denoted by x* is the set x* = {yGPUT \ 3 a : 
N{a) = (x,y)}. 

The CPN considered in this paper are the CPN satisfying three additional 
properties: 

1 . The number of places and transitions is finite. 

2 . The CPN is n-safe. 

3 . The CPN is S-finite. 



3 Branching Process of Colonred Petri Nets 

Let N be a Petri net. We will use the term nodes for both places and transitions. 
The nodes x\ and X2 are in conflict, denoted by xittx2, if there exist transitions 
<1 and t2 such that •tin*t27^0 and and (^2,2^2) belong to the transitive 

closure of N (which we denote by Rt). The node x is in self-conflict if x'^x. We 
will write X\<X2 if {x\,X2)&Rt and x\ < X2 if x\<X2 and X\^X2- We say that 
X CO y, or x\\y , or X concurrent y if neither x < y nor x > y nor x'^y. 

An Occurrence Petri Net (OPN) is an ordinary Petri net N = (P,T,N), 
where 

1 . P,T are the sets of places and transitions, 

2 . NC(P xT) 0 {T X P) gives us the incidence function, 

satisfying the following properties: 

1 . For all pGP |p|<l, 

2 . N is acyclic, i.e., the (irreflexive) transitive closure of iV is a partial order. 

3 . N is finitely preceded, i.e. for all xGPUT the set {yGPUT \ y<x} is finite 
which gives us the existence of Mm(N), the set of minimal elements of N 
with respect to Rt- 

4 . no transition is in self conflict. 

Let Ni = (Pi, Ti, fVi) and N2 = (P2, T2, N2) be two Petri nets. A homomor- 
phism h from N2 to Ni is a mapping h : P2UT2 — >■ PiUTi such that 

1. /r(P2)CPi and /i(T2)CTi. 

2. for all t€T2 h\.^ = *t^*h{f). 
for all t€T2 /i|(. = t*-^h{t)*. 

Now we give the main definition of the section. This is the first novelty of the 
paper, a formal definition of a branching process for coloured Petri nets. After 
the following definition, the existence result is given. 

Definition 1 A branching process of a CPN Ni = {Si, Pi,Ti, Ai,Ni,Ci,Gi, 
El, Ii) is a tuple (N2, ft., (/?, 77), where N2 = {P2,T2, N2) is an OPN, h is a 
homomorphism from N2 to Ni, ip and y are the functions from P2 and T2, 
respectively, such that 
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1 . (p{p)eCi{h{p)). 

2 . rj{t)€B{h{t)). 

Other requirements are listed below: 

3 . for allpiGPi EpGMm(N2) I h(p)=p^‘PiP) = Mo{pi), 

4 - G\{h{t)){r]{t)) for all t£T2- 

5 . Vf'sT 2 I ( 3 aG^i • -^i(a) = (p,t) h{t') = t) => 

Ei{a){iq{t')) = E(p'G*t' I h{p')=pMP')’ 

Vf'sT2 I ( 3 aG 7 li ; Ni{a) = (t,p) and hit') = f) => 

Eiia){r]it')) = Eip'ef \ h{p')=p)P{p') ^ 

6 . If {h{ti) = h{t2)) and (r]{ti) = p{t2)) and (*fi = *^2) then t\ = t2- 

Using the first two properties, we can associate a token element (p,c) of Ni with 
every place in N2 and the binding element (t,b) of Ni with every transition 
in N2. So we can further consider the net N2 as containing the places which 
we identify with token elements of Ni, and transitions which we identify with 
binding elements of Ni . So we sometimes use them instead, like /i((t, 6 )) = t 
means h{t') = t and r]{t') — b or p£*{t, b) means and h{t') = t and p{t') = b. 
Analogously, we can consider (p, c)cP2 as p'&P2 and h{p') = p and <p(p) = c. 
Also, h{p, c) = p and h{t, b) = t. 

It can be shown that any finite CPN has a maximal branching process (MBP) 
up to isomorphism (theorem 1 ). We can declare existence of the maximal branch- 
ing process when considering the algorithm of its generation. The algorithm is 
described in and the following theorem is proven there. 

Theorem 1 For a given CPN N there exists a maximal branching process 
MBP(N) 

This branching process can be infinite even for the finite nets if they are not 
acyclic. We are interested in finding a finite prefix of a branching process large 
enough to represent all the reachable markings of the initial CPN. This finite 
prefix will be called an unfolding of the initial CPN. 

4 Unfoldings of CPN 

A configuration C of an OPN N = (P, T, N) is a set of transitions such that t£C 
for all tQ<t , where to^C and for all ti^t2&C A set X^C-X of nodes 

is called a co-set, if for all ti,t2GXQ-. {ti co ^2)- A set XgCX of nodes is called 
a cut, if it is a maximal co-set with respect to the set inclusion. 

Finite configurations and cuts are closely related. Let C be a finite configu- 
ration of an occurrence net, then Cut{C) = iMin{N)UC*)*C is a cut. 

Let Ni = (S'i,Pi,Ti,Ai,A^i,C'i,Gi,Pi,/i) be a CPN and MBP(Ni) = 
(N 2 ,ft, ip,ri), where N2 = {P2’>T'2, N2) , be its maximal branching process. Let 
G be a configuration of N2. We define a marking Mark(C) which is a marking 
of Ni such that Mark{C)ip) = E(p'GC«t(C) | ft(p')=p)^ 2 (p')- 

Let N be an OPN. For all tGT the configuration [t] = {FgT \ t'<t} is called 
a local configuration. (The fact that [t] is a configuration can be easily checked). 
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Let us consider the maximal branching process for a given CPN. It can be no- 
ticed that MBP(N) satisfies the completeness property, i.e., for every reachable 
marking M of N there exists a configuration C of MBP(N) ( i.e., C is the config- 
uration of OPN) such that Mark{C) = M. Otherwise we could add a necessary 
path and generate a larger branching process. This would be a contradiction 
with the maximality of MBP(N). 

Now we are ready to define three types of cutoffs used in the definition of 
unfolding. The first two definitions for ordinary PNs can be found in [na. The 
last is the definition given in [8|. 

Definition 2 Let N &e a coloured Petri net and MBP(N ) be its maximal branch- 
ing process. Then 

1. A transition t&T of an OPN is a GT^-cutoff, if there exists t^GT such that 
Mark([t]) = Mark{[tf\) and [to]c[t]. 

2. A transition tGT of an OPN is a GT-cutoff, if there exists t^GT such that 
Mark{[i\) = Markift^]) and |[to]| < |[t]|- 

3. A transition tGT of an OPN is a EQ-cutofJ, if there exists t^GT such that 

a) Mark{[f\) = Marfc([to]) 

b) INI = IWI 

c) -(tpo) 

d) there are no EQ-cutoffs among t’ such that t'\\to and |[t']|<|[to]|- 



Definition 3 Eor a coloured Petri net N, an unfolding is obtained from the 
maximal branching process by removing all the transitions t’, such that there 
exists a cutoff t and t < t' , and all the places pGt'* . If Cutoff = GTq ( GT )-cutoffs, 
then the resulted unfolding is called GTq (GT) -unfolding. GTo(GT)-un folding is 
also called the McMillan unfolding. If Cutoff = GT-cutoffs U EQ-cutoff, then 
the resulted unfolding is called EQ-unfolding. 

It has been shown that the McMillan unfoldings are inefficient in some cases. 
The resulting finite prefix grows exponentially, when the minimal finite prefix 
has only a linear growth. The following proposition can be formulated for these 
three types of unfoldings m)- 

Proposition 1 EQ-unfolding < GT-unfolding < GT^-unfolding. 

The following theorem presents the main result of this section ( 0 )- 
Theorem 2 Let N &e o CPN. Then for its unfoldings we have: 

1. EQ-unfolding, GT-unfolding and GT^-unfolding are finite. 

2. EQ-unfolding, GT-unfolding and GT^-unfolding are safe, i.e., if C and C’ 

are configurations, then CGC' Mark{C')G[Mark(C)) . 

3. EQ-unfolding, GT-unfolding and GT^-unfolding are complete, i.e., 

Mg[Mq) there exists a configuration C such that Mark(C) = M. 
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In the general case the algorithm proposed in [12] and applied to coloured 
Petri nets in has an exponential complexity. The algorithm from [8| is rather 
efficient in the speed of unfolding generation. In the case of an ordinary PN 
it gives the overall complexity 0{Np-Nt), where Np and Np are the numbers 
of places and transitions in EQ-unfolding. This algorithm was also transferred 
to coloured Petri nets and a close estimation holds if we don’t take into 
consideration the calculation complexity of arc and guard functions. In this case 
we obtain O(Np-Nt-B), where B = max{\B{t)\ : t€.TcpN}- 



5 Unfoldings with Symmetry and Equivalence 

In this part the technique of equivalence and symmetry specifications for coloured 
Petri nets (CPN) will be applied to the unfolding nets of CPN. It will be shown 
how to generate the maximal branching process and its finite prefixes for a 
given CPN under the equivalence or symmetry specifications. All symmetry and 
equivalence specifications are taken from [B|. 

Let N be a CPN and M and BE be the sets of all markings and bind- 
ing elements of N. The pair is called an equivalence specifica- 

tion if is an equivalence on M and is an equivalence on BE. M~ 
and BE- are the equivalence classes. We say (h,M)K.{b* ^M*) iff bKipEb* 
and Let us have ACM and YCM-, then we can define: [X] = 

{MgM I 3xGX : M^iMx} — the set of all markings equivalent to the mark- 
ings from X and [Y] = {MgM | 3yGY : MGy} — the set of all markings 
from the classes from Y. The equivalence specification is called consistent if for 
all Mi,M 2 G[[Mo)] we have MipcmM 2 => [Next{Mi)] = [Next{M 2 )], where 
Next{Mi) = {{b,M)GBExM\ Mi[b)M}. 

A symmetry specification for a CP-net is a set of functions ^ C [Ts/LUBE — ^ 
Muse] such that (<^,*) is an algebraic group and : (^|mG[M— :^M] and 

(P\be^[BE^BE] . Each element of ^ is called a symmetry. A symmetry specifica- 
tion is it consistent iff the following properties are satisfied for all symmetries 
all markings Mi,M 2 G[Mo) and all binding elements bGBE = Mq 

and Mi[b)M 2 ^cl){Mi)[(l){b))(l)lM 2 ). 

Now the cutoff criteria will be defined for a CPN with a symmetry specifi- 
cation <l> or equivalence specification fi. We call the finite prefix of the maximal 
branching process of CPN obtained by using new cutoff criteria an unfolding 
with symmetry Unf^ or unfolding with equivalence Unf~. Since accordingly 
to described above we can consider the symmetry specification as the case of 
equivalence specifications, we give the cutoff definitions only for equivalence 
specifications. 

Taking into consideration the consistency of the regarded equivalence, we 
can conclude that it is sufficient to consider the classes [M] in our definitions of 
cutoffs. The classes of binding elements will be obtained in a natural way. 

Definition 4 Let N &e a coloured Petri net and MBP(N ) be its maximal branch- 
ing process. Then 
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1. A transition tGT of an OPN is a GTq~ - cuttoff if there exists to€T sueh 
that M ark{[t])KiM ark{[to]) and [io]c[t]. 

2. A transition tGT of an OPN is a GT~ -cutoff if there exists t^GT such that 
Mark{[t])peMark{[tQ\) and |[io]| < 

3. A transition tGT of an OPN is a EQ~- cutoff if there exists t^GT such 
that 

a) Mark{[f\)KiMark{[to]) 

b) INI = IWI 

c) -(tpo) 

d) there are no EQ-cutoffs among t’ such that t'\\to and |[i']|<|[<o]|- 

The notion Unf~ is used for any type of unfoldings. 

Proposition 2 EQ~ -unfolding < GT~ -unfolding < GTq~ - unfolding. 

The following theorem presents the main result of this section [2] . 

Theorem 3 Let NS be a CPN and ~ = {~Mt~be) be a consistent equivalence 
on N. Then for an Unf~(N) we have: 

1. [M]g[[Mo]) 4=^ 3(7, a configuration o/[/n/~(N) | Mark{G)K,MNl . 

2. GgG' and C’ is a configuration ofUnf~{NS) 4=> [Mark{G')]£[[Mark{G]]) . 

6 Net Examples 

Figures 1, 2 show us the dining philosophers CPN and its unfolding with the 
symmetry specification. 




val n = 3 

color PH = index ph with 1 ..n 
color CS = index cs with l..n 
var p:PH 

fun Chopsticks(ph(i)) = 

=1 ’cs(i)+l ’cs(if i=n then 1 
else i+1) 



Fig. 1. The dining philosophers example 



As is seen from the pictures, using the symmetry we obtain a much smaller 
prefix when constructing the Unf~ . However the size of the state space of the re- 
spective OE-graph (0-graph with equivalence) for this example is just two states. 
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Fig. 2. The unfolding with symmetry 



To avoid an impression that given an equivalence specification it is inefficient to 
use unfoldings let us consider the CPN representing the producer-consumer sys- 
tem |7] (see Appendix). We consider the case when the buffer capacity nb = 1. 
As an equivalence specification, the abstraction from the data di and d ,2 is con- 
sidered. The table 1 represents the results. 

Let us notice that we should generate EQ-unfolding when using the symmetry 
specification. In the case of equivalence specifications in general we can use all 
types of unfoldings. 

7 Conclusion 

In this paper the unfolding technique proposed by McMillan in [12j and devel- 
oped in later works is applied to coloured Petri nets as they are described in 
16T7I . The technique is formally described, the definition of a branching process 
of CPN is given. The existence of the maximal branching process and the im- 
portant properties of CPN’s unfoldings are proven. All the necessary details are 
presented in j9]. 

The unfolding is a finite prefix of the maximal branching process. To truncate 
the occurrence net, we consider three cutoff criteria in the paper. To construct 
the finite prefix, two algorithms of unfolding generation were formally trans- 
ferred from the ordinary PN’s area . The complexities of these algorithms are 
discussed in this paper. 

One of the important novelties of the paper is the application of the unfolding 
technique to CPN with symmetry and equivalence specifications as they are 
represented in |7]. The size of unfolding is often much smaller than the size of the 
reachability graph of a PN. Using the symmetry and equivalence specifications in 
the unfolding generation, we can additionally reduce the size of CPN’s unfolding. 
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We require a CPN to be finite, n-safe and to contain only finite sets of colours. 
In the future it is planned to construct finite unfoldings of Timed CPN as 
they are described in |^, using the technique of unfolding with equivalence (the 
first results are already obtained in [10]), and also to make all the necessary 
experiments with unfoldings of coloured Petri nets including the implementation 
of the model-checking method. 

Acknowledgments. I would like to thank Valery Nepomniaschy for drawing 
my attention to this problem and Elena Bozhenkova for valuable remarks. 
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Appendix 




Fig. 3. Producer-Consumer system 



This net example is taken from [7] and represents the producer-consumer system. 
We consider the case when nb=l. Let us calculate here the sizes of reachability graphs 
and unfoldings for the producer-consumer system. 

The number of reachable markings is 

N = {1 + nc + 2-nc-nd + 2-nc-nd^)'^^ -{I + np + 2-np-nd + 2-np-nd^)'^'^-{l + 

np-nc-nd?). 

The unfolding consists of four parts (we denote it by PA, PB, PC and CA). When 
a producer initially produces data, the part PA is working. Part PB may work after a 
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producer laid the first data to the buffer, but a consumer still cannot begin his part. 
Finally, PC is the part when a consumer definitely begins his work and a producer 
fulfills the buffer again. A consumer has the unique part CA. We have \PA\ = \PB\ = 
\CA\ = 5 and IPCI = 4. The whole size is 19. When adding either one more producer 
or one more consumer, we come to the situation of doubling of \PA\, \PB — 1| and 
\CA\ and adding the square of the number of parts \PC + 1|. Adding one more data 
acts as adding the square number of possibilities. Finally the size of the unfolding is 

UnfSize = \PA\-np-nc-nd^ + \ C A\-np-nc-nd^ + 

\PB — l\-np-nc-nd^ + \PC + l\-{np-nc-nd^)^ . 

As an equivalence specification, the abstraction from the data di and d 2 is consid- 
ered. For a graph this means that we can put nd=l. In the case of unfolding we obtain 
the additional (nd-1) transitions in the part PA. The whole size of EQ-unfolding with 
this equivalence is 

UnfSize~ = IPAI-np-nc-blCAI-np-nc-t-IEB— l|-np-nc-l-|T’C-l-l|-(np-nc)^-l-(nd— 1). 
The table below represents the results. 



Table 1. 
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Abstract. A multi-tier methodology is required in order to make a 
smooth transformation from one stage to the next in the course of 
software development under a consistent conceptual framework. We 
present, in this paper, a multi-tier behavior inheritance modelling 
method based on Petri Nets, which is illustrated through STLEN and 
DCOPN that are two net models serving as the tools for describing 
behaviors at two consecutive modelling tiers respectively. 

Keywords: Concurrency, Object Orientation, Petri Net, Behavior In- 
heritance, Modelling Method. 



1 Introduction 

The integration of Petri Nets with object orientation techniques has become 
promising ([l]-[8]). Parallelism, concurrency and synchronization are easy to 
model in terms of Petri Nets, and many techniques and software tools are already 
available for Petri Net analysis. These advantages have made Petri nets quite 
suitable to model the dynamic behavior of concurrent objects. 

A concurrent object-oriented system consists of a dynamically varying con- 
figuration of concurrent objects operating in parallel. For different stages in the 
software development of such sort of systems, diversified Petri Net models may 
be found in the literature to perform the specification and/or verification of sys- 
tem behavior respecting that stage. Some net models are suitable to be used 
during the earlier stages ([5] [7] [8]), and others during later ones ([1][3][4][6]). Up 
to now, however, there is a lack of net-based formal methods that will guarantee 
a smooth transformation from one stage to the next under a consistent concep- 
tual framework. This has prevented net-based methods from being more widely 
applied to the modelling of a concurrent object-oriented system, since incremen- 
tal developing is one of the principles in object-oriented methodology. So we are 
persistent on the opinion that multi-tier methodology is necessary. Each tier is 
a significant specification phase in which one net-based model may be chosen as 
the modelling language. A multi-tier method should guarantee that the system 

* This work was Supported by the National Natural Science Foundation of China un- 
der grant No. 69973003, and by the China NKBRSF (973) under grant G1999032706. 
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behavior specified in one tier to be preserved in its successor tier, though the 
specification in the successor tier is usually more detailed. 

A practical multi-tier method should take into account all the primary el- 
ements of concurrent object-orientation, such as object (class) representation, 
inheritance, aggregation, cooperation (association), concurrency (intra/inter ob- 
jects), etc. In this paper, we present a multi-tier behavior inheritance modelling 
method, and two Petri Net models, belonging to two tiers respectively, serve as 
the illustration of this method. The net model in the super-tier is a modified EN- 
system, called STLEN, in which both S-elements and T-elements are labelled. 
And in the successor tier (or sub-tier) is a net model, called DCOPN , which has 
s flavor of concurrent object-oriented programming languages, like net models 
in [1], [3] or [4]. 

The net models STLEN and DCOPN are briefly introduced in section 2 and 
section 3 respectively. In section 4, the multi-tier behavior inheritance modelling 
method is discussed, illustrated by the two-tier method. And finally in section 5, 
a general engineering guide (steps) for the method is presented as the conclusion. 

2 Object Petri Net Model STLEN 

STLEN is an extended net model to the Elementary Net System[14] model, 
with a higher abstraction tier. A STLEN system is obtainable through labelling 
an EN-system, both the S-elements and T-elements being labelled. The labelling 
leads to dividing the elements into groups, which makes a STLEN system possess 
a particular abstraction for methods and attributes, i.e., an observable group of 
S-elements may compare with a subset of the attribute set, and an observable 
group of T-elements may be compared to a method. 



pi 


empty 


^i 


put 


pi 


State empty 


gi 






p2 


partial 


g2 


put 


p2 


state lartial 


g2 


p3 


— 


S3 


put 


p3 


state full 

> 


g3 



(a) EN System (b) STLEN System 



Fig. 2.1. Bounded buffer 



Fig 2.1 (a) is an EN system that is the behavior specification of a bounded 
buffer. The state of a buffer is described with three S-elements empty, partial 
and full (the buffer size is assumed to be greater than 2). The T-elements pi, 
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p2 and p3 are used to represent the possible put actions in different cases of the 
buffer state, and the T-elements gl, g2 and g3 are related to get actions in the 
same meaning. 

In building an object model for a bounded buffer, it is natural to use an 
attribute group named state to hold the current state of the buffer, and to let 
it have two public methods put and get. Fig 2.1(b) is a ST-Labelled EN system 
whose underlying EN system is the one in fig 2.1(a). In this STLEN system, the 
T-elements pi, p2, p3 are labelled by put, and gl, g2, g3 are labelled by get] the 
S-elements empty, partial, full are labelled by state 

Fig 2.2 is another example of STLEN systems. A lockable bounded buffer 
is a bounded buffer that has one more attribute group about the state of its 
“/ocfc”, and two more methods, which can change the state of this attribute. As 
an example for discussing the inheritance in this paper, the class (templet) of 
lockable bounded buffers is supposed to inherit the class (templet) of bounded 
buffers. For the sake of the inheritance depicted in fig 2.2(a), the STLEN system 
diagram of a lockable bounded buffer in fig 2.2(b) is a reduced version by leaving 
out the unchanged part inherited from the diagram in fig 2.1(b). 



lock put put 




(a) Inheritance (b) Reduced STLEN system 



Fig. 2.2. Lockable bounded buffer 



3 Object Petri Net Model DCOPN 

DCOPN is a colored Petri net model, with a relatively low abstraction tier. By 
contrast to the STLEN model, DCOPN is enriched by many static details. A 
DCOPN class net is a net structure specifying the dynamic behavior of a class / 
object. A DCOPN system consists of the instances of many DCOPN class nets 
and has a dynamic configuration. 
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The right part of fig 3.1 is a DCOPN class net diagram for a bounded buffer. 
Doubled circles are method port places. Put is a call like method, which has one 
accept port place, put{a). Get is a call /return like method has two method port 
places, one result port place, get{r), and one accept port place, get{a). Some 
places serve as state port places, which can be used for constructing attribute 
predicates. For example, in and out are two state port places, which are used in 
the definitions of the attribute predicate empty, partial and full. An attribute 
predicate may be accessed (read only) by outside of the object (an instance of 
the class net) . The color (type) name of a place is written on the near top or left 
of the place. Arcs (starting from a place) with a small circle at their beginning 
ends are test arcs ([11]). 




Fig. 3.1. DCOPN class net of a bounded buffer 



The left part of fig 3.1 includes the declarations for the class net in the right 
part of the figure, constants, types, attribute predicates, method signatures, 
guard conditions and action expressions of T-elements, etc. The attach function 
would attach a reference to an instance object. In DCOPN, a token representing 
an object is valued to a reference of that object, instead of its identifier. 




Fig. 3.2. DCOPN class net of locable bounded buffer 

Fig 3.2 represents a DCOPN specification for a lockable bounded buffer. 
Similar to the situation in fig 2.2, fig 3.2 is a reduced version, with both the 
declaration and the diagram parts being reduced for the sake of the inheritance. 
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4 Multi-tier Inheritance Modelling Method 

4.1 Behavior Preserving Relation between Specification Tiers 

Let DCOPN be the subsequent net model of STLEN in our multi-tier modelling 
method. For the behavior preserving from a STLEN tier net to its corresponding 
DCOPN one, a restricted bisimulation relation, denoted by =, between them 
has been defined. The word restricted conforms to the incremental design pro- 
cess from the STLEN tier to the DCOPN tier, i.e., the specification in the later 
is more detailed, or more restricted. Furthermore, the definition of the relation 
is based on the grouping of S-elements. 

Let El be the STLEN system in fig 2.1(b), and E'^ be the DCOPN class net 
in fig 3.1. A relation 

Rstate = {{{empty}, empty), {{partial},partial) , {{full}, full)} 

can serve as a restricted bisimulation, which is a relation from p{{empty , partial , 
full}), the powerset of all the S-elements in the S-elements group state in Ei, to 
{empty , partial , full}, a subset of all the attribute predicates in E[. Since state 
is the only S-elements group, we have Ei = E[. 

Let E 2 be the STLEN system in fig 2.2(b), and E '2 be the DCOPN class net 
in fig 3.2. For the S-elements group state and lockstate in E 2 , relations 

Rstate = {{{empty}, empty), {{partial} , partial) , {{full}, full)} 



and 

Riock^state = {{{locked} , locked) , {{unlocked} , unlocked)} 
can serve as the restricted bisimulations respectively. So we have E 2 = E 2 - 

4.2 Subtyping Relation Preserving 

The term inheritance has often twofold meanings in the literature: the “code” 
reuse and the behavior preserving. In many places and also in this paper, the 
later is the meaning for another term subtyping, and the term inheritance stands 
simply for the former. In the situation of sequential object orientation, we do 
not usually distinguish between inheritance and subtyping, but it is very helpful 
to emphasize the distinction between them in the issues of concurrent object 
orientation, for example, in the comprehension of inheritance anomaly[\2\. 

In the net-based multi-tier behavior inheritance modelling method of this 
paper, the subtyping relations are supposed to be preserved under the behavior 
preserving relations between two consecutive tier net models. We illustrate this 
in fig 4.1 by the two tier situation from the STLEN tier to the DCOPN tier, in 
which the relation < can be preserved to the relation <’ under the restricted 
bisimulation relation =, where < is the subtyping relation between STLCN nets, 
and <' is the one between DCOPN nets. Each Si represents a STLEN net, and 
each S'i a DCOPN net. The relation ^ represents the least subtyping relation 
between two DCOPN Nets, which makes the interface of a subtype net usable 
in any context in which the interface of one of its supertype nets can be used. 
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Fig. 4.1. Subtyping relation preserving 



To satisfy ^ is a prerequisite in the definition of <' , which is the requirement 
to conform to the Principle of Substitutability [13]:d.n instance of a subtype can 
always he used in any context in which an instance of a supertype was expected. 



STLEN Tier DCOPN Tier 




Fig. 4.2. Incremental inheritance preserving 



One of the choices for the definition of < is the one in [9,10], which is a bisim- 
ulation based on the grouping of S-elements and in terms of blocking or encapsu- 
lating actions, i.e., the observable actions special to the subtype objects are to be 
inhibited in the context of the supertype objects. As an example, an instance of 
E 2 will behave like an instance of E\, if actions lock and unlock are blocked. The 
bisimulation relation may be i? = {{{empty}, {empty}), {{partial}, {partial}), 
{{full}, {full})}, which is a relation from p{{empty, partial, full}), the pow- 
erset of all the S-elements in the S-elements group state in E\, to p{{empty, 
partial, full}), the powerset of all the S-elements in the S-elements group state 
in A 2 . So we have E 2 < Ei. Usually a bisimulation relation in establishing a 
relation < between STLEN systems is an union of such relations like R. 

The definition of <' in [10] is based on a bisimulation relation between 
the sets of attribute predicates of two DCOPN nets, also in terms of block- 
ing actions. For example, a bisimulation relation from E{ to E'2 may be 
R' = {{empty, empty), {partial, partial), {full, full)}. Besides, to satisfy ^ is 
a prerequisite condition as stated above. In this example, the relation E '2 E 
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simply demands that the covariant and contravariant rules as in [15] are hold 
for the methods put and get. These are evidently true. So we have S 2 

For the definitions of <, <', = and -< in [10], we can verify the proposition 
showed in fig 4. 1 . This proposition is required to be valid for every two successive 
specification tiers, which should be guaranteed when the multi-tier method is 
built. 



4.3 Incremental Inheritance Preserving 

Subtyping is a behavior preserving relation. Instead, inheritance is used for the 
code/specification reuse. Practically, to implement the behavior preserving while 
the code/specification is also easily reused, some incremental inheritance relation 
paradigms, capable of implementing the anticipant subtyping relations, need to 
be developed [8], the more the better. In our multi-tier inheritance modelling 
method, incremental inheritance relations are required to be preserved from the 
super-tier to the sub-tier, i.e., the THEN part in Figure 2 holds. One of the 
possibilities to obtain this is to ensure the IF part in fig 4.2 to be satisfied. 

5 Modelling Steps 

The following is a guide for the behavior inheritance modelling method in this 
paper: 

(1) With the help of any OOA/OOD methodology, develop the behavior 
model of objects/classes using the net language STLEN and its available tools 
(to be developed). Label both the states (places) and actions (transitions), and 
the same time divide the states into groups according to the attributes. 

(2) Develop DCOPN nets from STLEN ones by adding details, such as data 
types, constants, and attribute predicates. Build a map between the STLEN tier 
and the DCOPN tier in the same time when a DCOPN net is developed from 
its corresponding STLEN one. The map will be used in the verification of the 
restricted bisimulation relation =. 

(3) Complete the interface specification for each DCOPN net. Verify the 
relation =. 

(4) For the behaviour inheritance (subtyping) modelling, just consider the 
derived net in the STLEN tier first. Then develop the DCOPN net from the 
derived STLEN one according to (2) and (3). Don’t forget that the interface 
specifications for each super DCOPN class net and its derived DCOPN class 
net, developed from STLEN one, have to satisfy the least subtyping relation 

(5) Develop and use incremental inheritance paradigms as many as possible. 
This may substantively save the work, as illustrated in fig 4.2. 

(6) Changes in the modelling process are allowable, which is simplified in our 
method since the direct corrections in the DCOPN tier may be avoided. 

Many aspects for the multi-tier methodology still need to be explored. Re- 
searchers who are interested in it may find many new topics about it. 
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Abstract. Specification based testing facilities are gradually becoming 
software production aids. The paper shortly considers the current state 
of the art, original ISPRAS/RedVerst experience, and outlines the ways 
for further research and testing tool development. Both conceptual and 
technical problems of novel specification based testing technologies in- 
troduction are considered. 



1 Introduction 

The specification based testing (SET) progressively moves from academic re- 
search area into real-life practice. The process of learning to handle SET tech- 
niques has to overcome a lot of problems related to both technical and hu- 
man/management facets of software development. Eelow we focus on technical 
problems, namely, on issues of specification and test suite development or, more 
specifically, we try to answer the questions: 

— Why limited use — why SET has not been widely introduced in industry 
practice yet? 

— What is the best specification approack0? 

— Which feature first — which SET features should be provided first? 

The work is mainly grounded on the practical experience of RedVersl0 
group of ISPRAS |27| . The experience was gained from industrial projects 
under contracts with Nortel Networks (http://www.nortelnetworks.com). Ad- 
vanced Technical Services APS and research projects under grants of RFER 
(http://www.rfbr.ru) and Microsoft Research (http://www.research.microsoft.com). 

* The work was partially supported by RFBR grant No. 99-01-00207 and Microsoft 
Research grant No. 2000-35. 

^ We mainly consider the common Application Program Interface (API) testing and 
basically we do not focus on specific specification and testing methods intended for 
a specific kind of software like telecommunication, compilers, databases, and so on. 
^ RedVerst stands for Research and development for Verification, specification and 
testing. 



D. Bj0rner, M. Broy, and A. Zamulin (Eds.): PSI 2001, LNCS 2244, pp. 287-|30^ 2001. 
(c) Springer-Verlag Berlin Heidelberg 2001 
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2 State of the SBT Practice — Why Limited Use? 

State of the SBT art is very dynamic. During the last 5-6 years, a lot of sound 
results have been produced in research and industry spheres. The attention of 
academic researchers in formal specification is being shifted from analytical ver- 
ification to problems of test generation from formal specification. The consider- 
able number of testing tool producers have announced features related to SBT. 
The most progress has been achieved in specific areas like telecommunication 
protocol testing. There are successful attempts to deploy formal specification 
and SBT features for verification and validation of wide spectrum of software in- 
cluding API testing. But most commercial tools/ technologies provide features for 
only partial specification (like assertions that describe only a part of functional- 
ity) . The technologies do not provide instructive methodologies for specification 
and test design. Therefore, the deployment of the technologies faces troubles in 
scalability of the approach in real-life projects. Other important problems are the 
integration of SBT tools and techniques with widely used Software Development 
Environments (SDE) and the introduction of the new activities in the conven- 
tional Software Development Processes (SWDP). No one SBT tool does provide 
a complete set of features that meet common requirements of specification and 
test designers. Instead, these tools try to suggest a “best and unique solution” 

. ADL/ADL2 story is a sad example of such approach. The ADL/ADL2 family 
of specification notations provided quite powerful and flexible features for spec- 
ification of C, C-|— k, and Java interfaces functionality. Nevertheless, test design 
problems (both methodological and tool support ones), especially in context of 
00 testing, were neglected. It seems that this reason has caused the refusal 
of ADL use in industrial practice. As promised, we restrict our consideration 
to only technical issues. However, the exhaustive answer to the above heading 
question has to involve, in addition, human and management facets (see more 
detailed consideration in mm)- 

3 Specification Approaches — What Is the Best? 

There are a few kinds of classification of specification approaches like model- 
oriented vs. property-oriented and state-based vs. action-based. To shortly re- 
view advantages and drawbacks of the specification approaches we will hold to 
following classification: executable, algebraic (usually, co-algebraic), use cases or 
scenarios, and constraint specifications (some specification kinds like temporal, 
reactive, etc. are outside of our consideration because their specifics). 

Executable specifications, executable models. This approach implies develop- 
ing a prototype to demonstrate feasibility and functionality of further imple- 
mentation. The examples of the approach are SDL 12D], VDM [19128126] . explicit 
function definitions in RAISE m- Finite State Machines (FSM) and Petri nets 
could be considered as (more abstract) executable specifications too. 

Algebraic specification provides a description of properties of some operations’ 
compositions (serial, parallel, random, etc.). Usually this approach is tightly re- 
lated to axiomatic approach m- SDL follows this approach to specify data 
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types HED]; RAISE [2] provides quite powerful facilities for axiomatic specifi- 
cation. 

Use case/Scenario based specification approach suggests considering the sce- 
narios of use instead of properties of the implementation. The approach is 
developed and propagated by OMG/UML community [28]. SDL community 
uses MSC jT4| notation for scenario description. The informative review of the 
scenario-based testing techniques is presented in [I^ . 

Constraint specification implies a description of data type invariants and pre- 
and post-conditions for each operation (function, procedure). There are specific 
techniques for 00 classes and objects specification. The constraint specification 
approach is followed by VDM [US], Design-by-contract in Eiffel m, implicit 
function definition style in RAISE, iContract [m|, ADL [22j . 

From the testing perspective, the advantages and the drawbacks of the spec- 
ification approaches could be evaluated by simplicity of the specification devel- 
opment and simplicity of the test derivation from the specification. For example, 
algebraic and FSM-like specifications are very suitable for the test sequence gen- 
eration including the case of concurrent and distributed software. However, the 
approach provides very restricted opportunities in test oracl^ specify their soft- 
ware using only algebraic or FSM approach. Besides, the algebraic specification 
is a non-scalable approach. Such specifications for a toy example are very short 
and attractive, however, as the size increases, the understandability of the alge- 
braic specification drastically drops (however, there exists a society of experts 
in algebraic specification who do not share this opinion) . 

So, in short, the heading question answer is “there is no the best specification 
approach” . Specification and test designers need good composition of specifica- 
tion techniques. One example of such composition is a combination of constraint 
and FSM specification used in um- Another example is SDL/MSC/TTCN 
composition that is widely used in SDL users’ society. 

4 RedVerst Experience and Lessons Learned 

Before answering third above declared question “Which feature first?” let’s dwell 
on the lessons learned from the RedVerst experience. ISPRAS organized the 
RedVerst group accepting the challenge of Nortel Networks in 1994. The origi- 
nal goal of the group was developing a methodology applicable to conformance 
testing of API of Nortel Networks proprietary real-time operating system. By the 
end of 1996, RedVerst has developed the KVEST methodology |7I8I16I25| . the 
specifications and the tools for test generation and test execution. The RAISE 
Specification Language (RSL) [21] was used for specification. The KVEST in- 
cluded techniques for automatic and semi-automatic test generation, automatic 
test execution and test result analysis and reporting. The techniques were ori- 
ented onto use in real-life processes, so, some practical requirements must be 
met like: fault tolerant testing, fully automatic re-generation, re-run of the tests 

® Test oracle is a decision procedure that automatically compares actual behavior of 
a target program (outcome of a target operation) against its specification M- 
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and test result analysis. The total size of KVEST formal specifications now is 
over 200 Kline. Six patent applications have been filed based on the KVEST 
research and development experience, a few patents have been taken out. 

The most valuable KVEST solutions were as follows: 

— A few kinds of test scenario schemes. The simplest scheme was intended 
for separate testing pure functions (without side effect) and allowed fully 
automatic test generation. The most complex schemes allow testing parallel 
execution of software like resource managers and messaging systems. 

— Enhanced test generation technique that allows excluding from consideration 
the inaccessible and redundant test situations. 

— Programming language independent technology scheme for test generation. 

— Automatic integration of generated and manually developed components of 
test suites for semi-automatic test generation. The technique allows avoiding 
any manual customization during repeated re-generations of test suites. The 
feature is valuable for both test design and regression testing periods. 

Up to now KVEST users have gained successful experience in verification of 
the following kinds of software. 

— Operating system kernel and utilities 

— Fast queuing systems for multiprocessor systems and for ATM framework 

— Telecommunication protocols as a whole and some protocol implementation 
subsystems like protocol parsers. 

Software verification processes. The KVEST has been applied in two kinds 
of software verification processes. First one is “Legacy reverse-engineering and 
improving process” and second one is “Regression testing process”. 

In addition, the RedVerst has suggested a specific SWDP called “co- 
verification” process. The process unites the target software design with the 
formal specifications and the test suites development in a concurrent fashion. 
One of the valuable advantages of the process is the production of the test suites 
before the target implementation is completed. Another important benefit of the 
process is a clear scheme of cooperative work of architects, designers and test 
designers. The “co- verification” advantages provide good opportunities for early 
detection of design (the most costly) errors. 

Lessons learned. On the one hand, the KVEST has demonstrated feasibility of 
SET use in industrial applications. On the other hand, the KVEST has been 
successfully deployed as technology for only regression testing. The customer 
has not undertaken roles of specification and test designers yet. Usually the 
similar problems of technology deployment are explained by resistance of users 
and managers in accordance to formal techniques as a whole. It is true, but 
there exist important reasons of the “resistance” . The reasons are common for 
KVEST and for many other SET technologies. The most significant reasons are 
as follows: 
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SBT technologies are usually bi- or three- 
lingual (a user has to write in specification, 
test design, and programming languages) 



SBT tool user does not have direct instruc- 
tions how to write specification and test sce- 
narios, how to re-use these artifacts. There- 
fore, there is significant re-work during spec- 
ification and testing evolving software. 



Difficulty of understanding structure of gen- 
erated code of test suite components, prob- 
lems in fitting the test suites for specific SBT 
user’s needs 



Multi-lingual tools 



No instruction 



Intricate generated 
code 



Problems of integration specification and test 
design tools with standard software develop- 
ment environment 



Non-coordinated 

tools 



How to introduce ‘extra’ works like formal 
specification in traditional work flow? 



‘Extra’ words 



Fig. 1. SBT problems 



5 Next Step — Which Feature First? 

To overcome these five problems, the five following solutions are suggested. 

“Multi-lingual tools” problem. It is the first well-recognized problem in SBT: 
what specification language (notation) should be chosen in a practical project. 
There are two main alternatives in the notation choice: the formal specification 
languages (like classical ones) and extensions of usual programming lan- 
guages. Both alternatives have advantages and drawbacks. The KVEST tech- 
nology followed the first way and has demonstrated feasibility of the approach. 
However, now it’s becoming evident that the second way promises more ad- 
vantages in the real-life industry context. The main argument for programming 
language extension vs. using formal specification language is the evident advan- 
tage of a monolingual system against a bi- or multi-lingual system. In addition, 
there are problems of involving software engineers into study and training in 
formal specification languages. 

The idea of programming language extension for specification purpose is not 
a novel one. The similar suggestions were discussed by B.Liskov, D.Parnas, and 
others in early 1970s. In the mid of 1990s C, C-I--I-, and Java were extended by 
joint X/Open Company Ltd. and the Sun Microsystems, MITI’s Information- 
technology Promotion Agency group |2Zli Java by R.Krammer [TU]. Eiffel [21] . 
VDM-SL and VDM-I— I- had originally facilities both for programming (proto- 
typing) and for constraint specification. 
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Multi-lingual tools 


■=> 


No instruction 




Intricate generated 
code 


■=> 


Non-coordinated 

tools 


■=> 


‘Extra’ words 





Program language extension 



— specification libraries, 

— test scenarios, 

— composing constraint and exe- 
cutable specifiations 



Open interfaces 



Integration of SBT with SDE 



SWDP improvement 



Fig. 2. UniTesK solutions 



Success of these extensions is quite restricted. Some of the tools/ technologies 
are used only as in-house tools, others are mainly used in academic area. The 
reason of the obstacle is weakness and incompleteness of features provided to 
a practical specification and test designer. As an example, in more details the 
drawbacks of ADL and iContract are described in another paper presented in the 
proceedings and on the RedVers web-site RedVerst has designed UniTesK 

concept of SBT using programming language extension. The concept is presented 
in [in]. 

“No instruction” problem. The tutorials, monographs, and manuals are nec- 
essary but not sufficient materials for SBT propagation. In addition to these 
materials, the software engineers need examples, prototypes, libraries of spec- 
ifications. The 00 approach opens new opportunity for architecture of these 
libraries |4I15J . Since specifications are usually more abstract than implementa- 
tion, so re-use of the specifications could be simpler. This opportunity is noted 
by Eiffel society m, but they use it only for rapid prototyping. An additional 
valuable advantage caused by introduction of formal specification in a software 
development process is the test suite component re-use, because these com- 
ponents are generated from re-usable specifications. RedVerst has developed 
the techniques for test suite re-use. The first one is intended for C-like software 
and uses template-based technology. The UniTesK approach expands the area 
of re-usable components and provides the 00 techniques for representation of 
storing artifacts and integration of the handmade and the generated artifacts 
into the ready for use 00 test suites. 
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As mentioned above, executable specifications, including FSM like speci- 
fications, are quite suitable for test sequence generation but have restricted pos- 
sibilities for test oracle generation. There is an evident idea: to unite executable 
and constraint specifications to gain advantages of both these approaches. How- 
ever, two obstacles prohibit from the union. First, it is doubling effort of specifi- 
cation design, and, second, there is a certain risk in developing the inconsistent 
parts of specifications. Some researchers try to derive executable specification 
from constraint specification automatically P2D3]. The idea seems to be quite 
attractive but cannot be applied to any kind of real-life software. RedVerst has 
developed the techniques for replenishment of constraint specification with im- 
plicit FSM specifications. This technique is briefly described below (see section 
6) and in more details in New kinds of FSMs differ in degree of deter- 

minism and timing characteristics of reaction appearing. The variety of FSMs 
allows generating the test sequences for wide spectrum of software including dis- 
tributed and real-time applications. FSM-based techniques allow generating an 
exhaustive test (in sense of the model). Sometimes (for example, for debugging) 
it is desirable to use non-exhaustive but some specific tests usually based on use 
cases or test scenarios. A union of scenario approach and FSM-based approach 
is used in UniTesK [3]. The technique allows describing the main idea (scenario) 
of a test case family and generating several test cases (using the implicit FSM 
technique) that belong to this family. 

“Intricate generated code” problem. It is a common problem of the tools gener- 
ating code from some sources; the intricate generated code is too complicated 
for understanding and debugging. A prospective solution is to design an open 
OO test suite architecture, where the generated and handmade artifacts 
are stored separately, in different classes, but are closely and naturally linked by 
means of usual relations used in OO design and programming. UniTesK presents 
an example of such OO test suite architecture 01151. 

“Non- coordinated tools” problem. The UniTesK dream is integration with ar- 
bitrary SDE based on some standard interfaces. UniTesK requirements in this 
case are as follows. SDE should provide facilities for: 

— SET tools invocation from the SDE 

— synchronization of the windows related to SET input/output 

— key words/syntax setting 

— diagnostic messaging. 

“‘Extra’ works” problem. Introduction of SET implies appearance of new ac- 
tivities, roles, and artifacts in SWDP. The specifications could be presented as 
informal (for example, draft functional requirement specification), semi- formal 
(like UML use cases), and formal specifications. The new artifacts raise the ne- 
cessity in new personnel, techniques, and tools - negative consequences. They 
allow well-organized and computer-aided requirements tracking, rapid prototyp- 
ing, and test and documentation generation - positive consequences. Therefore, 
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to take an advantage of SBT, an organization should invest some additional ef- 
fort to compensate possible negative consequences of this prospective technology 
(it is true for any novel technology). 



6 Go into UniTesK 

UniTesK is intended for SBT. Therefore, on the one hand, it is implied that a 
specification or a model exists, but on the other hand, testing must check the 
implementation not only on the robustness, but also on the conformance with 
the specification 0 A specification could be written, in principle, in any suitable 
specification (modeling) language. UniTesK proposes to use for this purpose not 
conventional specification languages, but extensions of usual programming lan- 
guages. It should facilitate introduction of UniTesK technologies in the industry 
practice. 

Let’s consider the basic components of the source for test generation and 
the structure of test suites and test harness 0 used in UniTesK. We begin with 
relatively simple kind of software - procedures (subroutines, functions, methods, 
etc.) that allow separated testing. I.e. no action of the system under test (SUT) 
is needed to set the SUT in the initial state, to form input test parameters, call 
the procedure under test, and evaluate its result. Most of the mathematical and 
string manipulation functions are examples of such procedures. 

What tasks should be solved by a test system in separated testing? They are 
as follows: 

— conduct partition analysis of the input space to be able to define the equiv- 
alence classes of the input test data; 

— form input test parameters (or generate a program that will form the test 
parameters in dynamics); 

— if the number of generated test cases is too large, test system should provide 
filters for test case selection (based on the above-mentioned equivalence class 
definitions); 

— invoke (probably, repeatedly, in a loop) the procedure under test with cor- 
responding parameters; 

— check correctness of the procedure result; 

— collect trace to get information on the detected errors and the achieved test 
coverage. 

Notice that the two tasks are simultaneously an advantage and a drawback. SBT 
allows to bridge functional requirements and implementation behavior, it is a positive 
facet. At the same time, the necessity of specification development extends time 
length and raises the cost of the software development. In addition, the specification 
needs personnel with specific skills. 

® Test harness in UniTesK consists of a test suite (specification and implementation 
dependent part of test program) and an invariant part of the test program (run-time 
support or operation environment of the test suite), that could be used for testing 
wide spectrum software on the platform. 
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Target S/W 
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Fig. 3. UniTesK test program architecture in the case of separated testing 



Is it possible to generate fully automatically a test suite that performs all 
the tasks? Sometimes it is possible! Thus, about 40% of procedures of the ker- 
nel interface layer of Nortel Networks switch OS allowed separated testing [^. 
For about half of them the test suites were generated fully automatically. For 
the rest of the procedures, data iterators were written “by hands”. The hand- 
made work appeared to be so simple, that the benefits of automatic generation 
are not too valuable. So, both “automatic” and “handmade” ways are possible, 
but in the second case we should be able to integrate the generated and the 
handmade components. A reader should keep in mind that “test generation”, in 
fact, is a phase of the industrial process that implies repeatable re-generation, 
re-integration, re-execution, and so on. So, the problem of integration of hand- 
made and generated components should be solved very carefully and efficiently. 
The integration requires elaborating the structure and the relations between all 
components of a test suite. 

Therefore, although sometimes a test suite can be generated fully automati- 
cally, in general case we have to generate a framework that includes common or 
pre-built parts, generated parts, and slots for handmade components. The test 
suite is integrated into an operating environment. The operating environment is 
the invariant part of test programs. Together a test suite and the invariant part 
are named the “test harness ” . Our experience showed that this way is quite ac- 
ceptable in industrial practice, because it provides flexibility and decreases test 
designer’s effort. 
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Testing of procedure groups, where the procedures share common data 
and/or testing 00 classes/objects, raises new problems. So, the architecture 
and the functions of test system is becoming more complicated. What are these 
new problems and tasks? Nominally, there is only one task: to define an order 
on invocations of the target functions. 
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Fig. 4. UniTesK test program architecture. General case 



An idea of FSM traversing underlies the UniTesK test sequence generation 
scheme. In principle, if we digress from the SET context, then the implementa- 
tion itself could play the role of the FSM. In this case, a state of global variables 
corresponds to the FSM state, and invocations of the target functions correspond 
to transitions between the states. However, firstly, FSM of a real-life software 
would be too big and complicated, and, secondly, we are interested in extraction 
of FSM from specification or providing a relation between the FSM and the spec- 
ification. So, we have to introduce a more “simple” FSM, which is a factorization 
(reduction) of the FSM given by the specification. As a result of factorization, 
the states of the reductive FSM correspond to classes of the source specifica- 
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tion states and the transitions of the reductive FSM correspond to classes of 
transitions in the source specification FSM (function invocations) or to a chain 
of transitions (sequence of invocations). UniTesK allows implicit description of 
FSM. Such description does not directly enumerate all states and all transitions. 
It turned out that for states we can define only a Boolean function that compares 
two states; for transitions user should define a function-iterator which builds the 
next invocation based on the history stored in the current node of the FSM. Our 
experience shows that such description is more simple (shorter and needs less 
effort) than an explicit description used, for example, in [12]. All changes in the 
test suite architecture can be seen in Figure 4. Thus, FSM traverser occupies the 
place of the main testing loop in Figure 3. The traverser is a unified program 
that can traverse (make transitions step-by-step to gradually cover all states and 
all transitions in the FSM) any FSM given by a test scenario. The particularities 
of the FSM, its relation to the target system (its mapping to the target system 
interface) are presented in Test Scenario. The Test Scenario is a base for Test 
Sequence Iterator. A Test Scenario, on the one hand, is bound to the target in- 
terface specification (it takes into account the target function/methods names, 
number and types of parameters and so on). On the other hand, the logic of the 
Test Scenario could be independent of the logic and the purpose of the target 
system. In the later case, test designer can use the library TestRunModel, as 
well as the library iterators and classifiers. 

FSM kinds. The proposed architecture of test suite is quite general. In particu- 
larly, it allows different kinds of FSM: deterministic, non-deterministic, partial 
cases of non-deterministic FSM. This opportunity has been used. So, a kind 
of non-deterministic FSM was used for testing storage allocation system. In re- 
search project under grant of Microsoft Research |2^ on testing of IPv6 protocol 
implementation, we used so-called “FSM with delayed reactions ” . This kind of 
FSM meets requirements of a wide range of distributed and telecommunication 
systems. As distinct from usual FSM, this kind of software has a non-usual par- 
ticular feature - for most states, a list of permissible reactions on the stimuli is 
known, but we do not know the time of the reaction and the order of expected 
reactions. So, stimuli and reactions form some intricate combinations and only 
a partial ordering is defined. 

The project has shown the flexibility of the UniTesK test suite architecture. 
To introduce such kind of FSM, we changed nothing except for the FSM tra- 
verser. The delayed reactions were mapped into oracles. These oracles operate 
with so-called hidden stimuli. The purpose of these oracles is to check whether 
a corresponding reaction has arrived yet and, if so, whether the order of the 
reaction is correct or not. 



7 UniTesK Foundation and UniTesK Program 

The fundamental distinction of UniTesK in formal method applications is the 
rejection of classical specification languages though they provide abstraction 
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features and strong semantics. Are UniTesK specifications and tests built on 
sand or not? 

Traditionally, specification and modeling pay very serious attention to strong 
semantics definition on the notation used. Otherwise, as researchers say, it is im- 
possible to treat and interpret the specifications (see, for example [30]). Notice, 
the above terms “treat” and “interpret” imply here an automatic analysis, rea- 
soning, analysis of conformance between specification and implementation. In 
this context, they are right. But Yu. Gurevich jSTj notices that requirements of 
modeling and reasoning are very different and have different effects on specifica- 
tion languages. Furthermore, we should distinguish between requirements caused 
by specification/description/modeling and requirements caused by a certain kind 
of reasoning. 

The analytical verification makes very strong demand to semantics definition 
of a specification language. Should SBT share this demand? It seems, no. Testing 
practice, as well as programming as a whole, does not meet any fundamental 
trouble caused by a vagueness of some programming language constructs and or 
test design languages. Why? 

The answer is simple: programmers avoid “dangerous” constructs and ob- 
scure operating situations. Following this principle, we can build specification 
extensions of programming languages and use these extensions. In other words, 
we do not require a specification extension to be more rigorous then a basic 
programming language. 

UniTesK represents a program consisting of a family of industrial and re- 
search activities. The common goal of this program is to develop and deploy in 
the real-life practice the techniques and tools supporting the SBT. As mentioned 
above, the first step on this way is development and introduction of specification 
extensions of programming languages together with tools for test generation, 
integration of the tools with the usual SDEs. Now we have developed extensions 
and tools for Java and C. VDM-I— l-TesK add-on tool has been developed for 
VDMTool box (here we consider VDM-I--I- as a programming language for rapid 
prototyping). In the nearest future, UniTesK will be implemented for C-|— k, C^, 
and VDM-SL platforms. 



8 Conclusion 

The paper presents an outline of current state of the art and prospective solutions 
of SBT problems. We focus on API specification testing because it is the base and 
most uniform level of software interfaces. This short review of SBT techniques 
did not consider whole variety of techniques known academic area. Our attention 
was only paid to the approaches have been used in real-life SWDP. 

There is no any unified approach for specification and SBT and inside each of 
these approaches there is no any unique tool that performs all necessary actions. 
It is rather well. However, the known research results and commercial tools have 
shown feasibility of SBT approach in real-life application of arbitrary complexity. 
To be introduced in practice any technology must provide at least minimal set 
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of features that meet the most needs, it is so-called critical mass. Above “Next 
step” solutions outline the critical mass. The era of toy examples and pioneer 
SBT projects is finishing. 
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Abstract. The article presents the advantages of J@va, a specification 
extension of the Java language, intended for use in automated test devel- 
opment. The approach presented includes constraints specification, au- 
tomatic oracle generation, usage of FSM (Finite State Machine) model 
and algebraic specifications for test sequence generation, and specifica- 
tion abstraction management. This work stems from the ISPRAS results 
of academic research and industrial application of formal techniques jl] . 



1 Introduction 

The last decade has shown that the industrial use of formal methods became 
an important new trend in software development. Testing techniques based on 
formal specifications occupy a significant position among the most useful appli- 
cations of formal methods. However, several projects carried out by the RedVerst 
group [131 12j on the base of the RAISE Specification Language (RSL) [6] showed 
that the use of specification languages like RSL, VDM or Z, which are unusual 
for common software engineer, is a serious obstacle for wide application of such 
techniques in industrial software production. First, the specification language 
and the programming language of the target system often has different seman- 
tics and may even use different paradigms, e.g., one can be functional and the 
other can be object-oriented, so a special mapping technique must be used for 
each pair of specification and target language. Second, only developers having 
special skills and education can efficiently use a specification language. The pos- 
sible solution of this problem is the use of specification extensions of widely used 
programming languages. 

This article presents J@va - a new specification extension of Java language. 
Several specification extensions of programming languages and Java in particular 
already exist. ADL [517] and iContract m are the most known of them. A few 
extensions have been used in industrial projects. Why do we invent a new one? 

Our experience obtained in several telecommunication software verification 
projects shows that the formal testing method used in industry should not only 
allow automated test generation but also possess features such as clear mod- 
ularization, suitable abstraction level management, separate specification and 
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test design, and the support of test coverage estimation based on several crite- 
ria M- These subjects did not receive sufficient attention in ADL and iContract 
languages and test development technologies based on them. The absence of inte- 
grated solution explains the limited use of specification based methods in general 
and these languages and related tools particularly. 

Every industrial test development technology should provide the answers on 
the following three questions. 

— How to determine whether the component of the target system behaves 
correctly or not? 

— How to determine the set of test cases, which makes the test complete in the 
sense that any additional test case can not add any important information? 
And how to estimate the results of the test, which does not contain all of 
these test cases for some reasons? 

— How to organize the sequence of target operations calls during the test, the 
test sequence, to obtain the necessary test cases in the most effective way? 

The first problem is usually solved with the help of the component’s oracle, 
which can be generated from the specification of the component. Although oracle 
generation techniques are known (see, for example, M), they are not widely 
used in industrial projects. KVEST project [5] performed by our group is the 
largest example of such a project in the European formal methods database [2]. 
We do not consider the issues of automated oracle generation in this paper to 
comply with size restrictions. We refer the interested reader to the previously 
mentioned works M. 

The solution of the second problem is very important for the industry. Usu- 
ally the solution is based on test coverage criterion, which gives the numerical 
measure of the test effectiveness. Coverage criteria based on the structure of the 
target code are widely known and used in the industry, but they are not suffi- 
cient. Such criteria show what part of target code is touched by the test. The 
important issue is also what part of functionality is touched by it. This problem 
can be solved with the help of specification based coverage criteria. 

The third problem mentioned above is addressed by FSM based testing tech- 
nique used in our approach called UniTesK technology (see m for details) . The 
approach uses FSM model of the unit under test. Such a model is developed on 
the base of the coverage criterion chosen to obtain. Then, the FSM developed 
is traversed, and, so, the target coverage is achieved. We call the description of 
this model the test scenario. Test scenarios directly deal with test design while 
specifications describe the abstract functionality of target system. 

2 Key Features of J@va Approach 

In this section we present the goals of J@va design and J@va key features, explain 
their advantages, and compare them with ADL and iContract. 

During the design of J@va language we tried to preserve the main features 
of our test development method, which is based on several previous successful 
projects (see 0). These features are as follows. 
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— Automatic generation of test oracles on the base of specifications presented 
as pre- and postconditions of target operations. 

— The possibility to define test coverage metrics and automatic tracking of 
coverage obtained during the test. 

— Flexible FSM based testing mechanism. 

— Dynamic test optimization for the target coverage criterion. 

Along with that we must simplify and clarify the method to make it appli- 
cable in the software industry, not only in the research community. 

Below we pay more attention to features not supported or supported in- 
sufficiently by J@va contenders. In particular, we do not consider the general 
software contract specification approach used in all mentioned languages n 
and methods to specify exceptional behavior. Parallel processing specification 
and testing methods are also out of the scope of this article. 

Specification of object state. J@va specifications are structured similar to Java 
code. The specification of the behavior of some component is presented as a 
specification class, which can have attributes that determine the model state, 
invariants representing the consistency constraints on the state of an object of 
this class, and specification methods representing the specifications of operations 
of the target component. Specification method can have pre- and postcondition. 
In ADL and iContract specifications are also presented as pre- and postcondi- 
tions, but they have no special constructs for state consistency constraints. The 
same effect can be obtained only by including such constraints into pre- and 
postconditions of all class methods. 

Axioms and algebraic specifications. J@va provides constructs to express arbi- 
trary properties of the combined behavior of target methods in an algebraic 
specification fashion. The semantics of J@va axioms and algebraic specifications 
is an adaptation of the semantics of RSL ones jB]. Axioms and algebraic spec- 
ifications serve as a source for test scenarios development - they are viewed as 
additional transitions in the FSM testing model. During testing we call the cor- 
responding oracle for each method call in an axiom and then check the global 
axiom constraint. Similar constructs can be found only in specification languages 
and are absent in specification extensions as ADL and iContract. 

Test coverage description. This is an essential feature for testing and software 
quality evaluation. Test coverage analysis also helps to optimize the test se- 
quence dynamically by filtering the generated test cases, because usually there 
is no need to perform a test case that does not add anything to the coverage 
already obtained. Each coverage element can have only one corresponding test 
case. The coverage consisting of domains of different behavior, called the specifi- 
cation branch coverage, can be derived automatically from the J@va postcondi- 
tion structure. J@va also has several special constructs for explicit test coverage 
description. The explicit coverage description and functionality coverage deriva- 
tion allow providing fully automatic test coverage metrics construction and test 
coverage analysis. Neither ADL nor iContract has facilities for test coverage 
description and analysis. 
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Abstraction level management. The ability to describe system on different ab- 
straction levels is very important both in forward and reverse engineering of 
complex systems. The support of abstraction level changing allows developing 
really implementation-independent specifications, whether we follow top-down 
design or bottom-up reverse engineering strategy. In J@va, specifications and 
source code are fully separated. Their interaction is provided by a special bind- 
ing code. This code performs synchronization of the model object state with 
the implementation object state and translates a call of model method into a 
sequence of implementation methods invocations. It is necessary, because test 
sequence is defined on the model level in our method. This approach allows 
using one specification with several source code components and vice versa, it 
also ensures the modularity of specifications and makes possible their reuse. No 
other of known Java specification extensions provides such a feature. Larch m 
provides the infrastructure the most similar to the J@va one but supports only 
two-level hierarchy. 

Test oracle generation. This is a standard feature of specification extensions 
intended to be used for test development. J@va, as ADL and iContract, supports 
automatic generation of test oracles from the specifications. 

Test scenarios. Test scenarios provide the test designer with a powerful tool 
for test development. The scenarios can be either completely user- written or 
generated on the base of once written templates and some parameters specified 
by test designer. In general, a J@va scenario defines its own FSM model of the 
target system, called the testing model. A scenario defines the state class for this 
model and the transitions, which must be described in terms of sequences of 
target method calls. The testing model should represent a FSM, which can be 
obtained from the FSM representing the target system by removing some states 
and transitions, combining a sequence of transitions into one transition and 
subsequent factorization. One can find details of this approach, some methods 
and algorithms of testing model construction in [in. where they are formulated 
in terms of FSM state graph properties. 

In a more simple case, test scenario represents the sequence of tested op- 
eration calls that can lead to some verdict on their combined work. The test 
constructed from such a scenario executes the stated sequence and assigns the 
verdict; it also checks the results of each operation with the help of the opera- 
tion’s oracle. 

J@va allows the use in scenarios such constructions as iterations, nonde- 
terministic choice and serialization. Iterations help to organize test case genera- 
tion for one target operation. J@va test scenario is represented as a class with 
special methods - so-called scenario methods, which represent the transitions of 
the model. 

Among existing Java extensions, only ADL provides some constructs for test 
case generation. However, complex tests, e.g. for a class as a whole, have to be 
written entirely in the target programming language. An essential shortcoming 
of this approach is the lack of state-oriented testing support that forces the test 
designer to spend considerable effort to ensure the necessary test coverage. 
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Open 00 verification suite architecture. The verification suite consists of speci- 
fications, test scenarios, binding code, and Java classes generated from the spec- 
ifications and the test scenarios. The set of classes and relations between these 
classes and between verification classes and target Java classes are well defined. 
The architecture is described in UML and is easy to understand by any soft- 
ware engineer having experience in design and development using Java language. 
The openness of the architecture does not mean necessity of the generated code 
customization for optimization or other purposes. There are other well-defined 
flexible facilities for fitting the verification suite. However the openness signifi- 
cantly facilitates the understanding and the use of the technology as a whole. 
ADL and iContract users could read (and reverse engineer) generated code, 
however the structure of generated test harness is considered a private issue of 
ADL/iContract translator and can be changed at any time. 



Example of J@va specifications. Here we give an example of J@va specifications 
for bounded stack class with non-null elements. This example demonstrates some 
of the features itemized above. 

specification package ru. ispras .redverst . se . java. examples . stack; 
import java. util. Vector; 

class StackSpecif ication { 

static public int MAX_S1ZE = 2048; 

public Vector items = new Vector (MAX_S1ZE) ; // model state 

// object intergity constraint 
invar ictnt 11 () 

{ 

return items. sizeO >= 0 && items. sizeO <= MAX_S1ZE; 

} 

// specification of popO operation 

specification public synchronized Object popO 

updates items.? // changes data available through items field 

{ 

pre { return items. sizeO != 0; } 
post 
{ 

branch "Single brcoich"; // defines single coverage element 
Vector old_items = items . clone () ; 

// method identifier refers to the result of operation 
old_items . addElement (pop) ; 

// @<expression> denotes the value of expression in pre-state 
return old_items. equals (Sitems. clone ()) ; 

} 

} 
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// specification of pushO operation 

specification synchronized void push(0bject obj) 
reads obj, updates items.? 

pre { return obj != null && items. size () != MAX_S1ZE; } 
post 

brainch "Sinlge brcuich"; 

Vector new_items = Sitems . cloneO ; 
new_items . addElement (obj ) ; 
return items . equals (new_items) ; 

} 

> 

// algebraic specifications 

equivalence synchronized Object push_pop (Object obj) 

{ 

pre { return items. size () != MAX_S1ZE; } 
alternative { push (obj); return popO; } 
alternative { return obj ; } 

} 

equivalence synchronized void pop_push() { 
pre { return items. size () != 0; } 
alternative { push(popO); return; } 
alternative { return; } 

} 

} 

3 Conclusion 

To become applicable in industrial software production, an automated test de- 
velopment technology must support a set of features that constitute something 
like a critical mass. The critical mass should be not too huge to be introduced 
in real-life software engineering and at the same time it should be sufficient for 
usual needs of software engineers. The J@va tries to achieve this goal. More de- 
tailed description of J@va and J@va based technology are presented on our web 
site [I]. 
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Abstract. Firewalls protect hosts in a corporate network from attacks. 
Together with the surrounding network infrastructure, they form a com- 
plex system, the security of which relies crucially on the correctness of 
the firewalls. We propose a method for specification-based testing of hre- 
walls. It enables to formally model the firewalls and the surrounding 
network and to mechanically derive test-cases checking the firewalls for 
vulnerabilities. We use a general CASE-tool which makes our method 
flexible and easy to use. 



1 Introduction 

The increasing connection of businesses and other organisations to the Internet 
poses significant risks: Attackers from the Internet may exploit vulnerabilities in 
the internal hosts connected to the Internet to gain unauthorised access to the 
corporate network. Due to the complexity of computer systems, it is impossible 
to protect an internal host just by making sure that it has no vulnerabilities. 

This motivates the use of firewalls |3] to protect a network from the Inter- 
net, or subnetworks from each other. Incoming and outgoing traffic is filtered 
and possibly dangerous services are blocked. Firewalls are complex systems com- 
posed of several hard- and software components the correct design of which is 
difficult, in particular for networks that use more than one firewall (e. g. larger 
companies). Here, the interplay between the firewalls could introduce vulnera- 
bilities. Absolute correctness of the firewall design and implementation is vital 
since a single weakness allowing unauthorised access makes it fail. However, test- 
ing firewalls is usually confined to applying simple check lists (e.g. m, possibly 
using specialised tools (such as |6]); the reliability of the process depends on the 
skill of the person in charge. 

We propose an alternative approach: we formally model a firewall system, and 
derive test sequences automatically from the formal specification — following the 
approach to specification-based testing of I17I18I13I . Testing the firewall with 

* This work was partially supported by the Studienstiftung des deutschen Volkes, and 
by the German Ministry of Economics within the FairPay project. 
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Fig. 1. The Network 



these test sequences provides more confidence that the firewall implementation 
actually provides the desired protection, than ad-hoc testing, especially since 
the test-sequences are derived with respect to the actual network topology. Our 
approach is embedded in an easy-to-use CASE framework [9]. Because of its 
generality, there are few restrictions on the model: Firewall rules need not be 
of a special form, stateful firewalls can be modelled etc. The network model is 
also flexible, allowing to model possible faults or Trojan horses (malicious code 
injected by attackers) at the hosts. Various scenarios, such as stress test, spoofing 
(source address forging), and policy violations, can be tested. Additionally, one 
can check the firewall specification with a model-checker. 

In the next section, we explain our approach using an example network. We 
then point to related work and conclude. 



2 Testing Firewalls 

In our approach, we give a (possibly partial) description of a network behaviour 
that presents a potential threat. From this, a test-sequence is derived automat- 
ically which indicates how the system should react to this threat according to 
the specification. This test-sequence can then be used for actual testing of the 
firewall. 

A further advantage of specification-based testing is that, given a sufficiently 
detailed specification, one can also determine which values internal variables 
need to have at certain points of the execution and can use this for more detailed 
debugging. 



2.1 Example Network 

We consider an example (in the following called the Network) similar to the one 
given in [3] (see Fig. [TJ. 
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Each interface has its own IP-address. The DMZ {demilitarised zone) con- 
tains a web-server, a DNS-server and a mail-server. 

Here we consider IP-based packet-filtering firewalls. The firewalls should im- 
plement the rule-bases that are specified below. Each rule specifies a source, a 
destination, a service-group, the direction of the packet, and the action to be 
taken. The source and destination are host-groups (sets of IP addresses), the 
service-group specifies a set of services (such as http/ https, smtp (e-mail), dns 
etc.), and the actions we consider here are to drop the packets of the correspond- 
ing session, or to let them pass (for space limitations we do not consider other 
actions that may be possible, such as writing a log). The service corresponding 
to the packet can generally be inferred from the number of the source or desti- 
nation port given in the packet. Here we can only give a few examples of such 
rules: 

— let packets pass only if the direction of the packet complies with the topology 
of the network wrt. its source and destination (what this means should be 
obvious in our simple example, e. g. F3 should let a packet out to the Home 
subnet via the connection 100.200.4.1 only if its source is in the Firewall 
Admin, the DMZ or the Corporate subnets and the destination is in the 
Home subnet, F4 should let packets from the Internet into the Home network 
only if the source address is in the Internet and the destination address in 
the Home network, etc.) 

— let packets with source in the Corporate subnet and destination in the In- 
ternet through 

— let packets between the mail-server and the Internet, or the Corporate or 
Home subnets pass if the service is smtp 

— let packets between the DNS-server and the Internet, or the Corporate or 
Home subnets pass if the service is dns 

— let packets from the Internet, or the Corporate or Home subnets to the 
web-server pass if the service is http or https 

For example, a packet with source address in the DMZ and destination ad- 
dress in the Internet will be dropped by F3 (by the first rule, since its destination 
address is not in the Home subnet) and can only go directly via F2 to the Internet 
(and similarly for the reverse direction). 



2.2 Formal Model 

We modelled the network containing the firewalls with help of the CASE tool 
AuTOFocus/Quest. AuTOFocus [9ll()j is a tool for graphically specifying dis- 
tributed systems. It is based on the formal method Focus, therefore the models 
have a simple and clear formally defined semantics. AutoFocus supports differ- 
ent views on the system model, describing structure, data types, behaviour and 
interactions. These views are related to UML-RT diagrams. In addition to mod- 
elling, AutoFocus offers simulation, code generation, test sequence generation 
and formal verification of the modelled systems. 
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Fig. 2. SSD for firewall system 



The structural view on our example network system is depicted in Figure 
1^ as an AutoFocus system structure diagram (SSD). Each network component 
(subnets and firewalls) is an AutoFocus system component, drawn as a rect- 
angle. These components can exchange data via named channels, which connect 
output and input ports (filled and empty circles). In addition, there is a special 
component PacketGenerator that produces a random packet and sends it to one 
of the other components, so that it can start travelling through the network. 

The data type definition in the model describes network packets, and a 
function for a consistency condition on packets. As other data types in Auto- 
Focus, they are defined in a functional style, as follows: 

data TAddress = FWAdmin I Corporate I DMZ I Internet I Home I 
FI I F2 I F3 I F4 I Mail I DnsSrv I WWW; 
data TService = Http I Https I Smtp I Dns I Ping I Ssh; 
data TPacket = Packet (source : TAddress, dest: TAddress, 
service: TService); 
data TSignal = Present; 

fun srvKons (Mail, Smtp) = True I srvKons (DnsSrv, Dns) = True 
I srvKons (WWW, Http) = True I srvKons (WWW, Https) = True; 

Finally, each component in the network model is assigned a specified behaviour, 
using state transition diagrams (STDs). STDs correspond to extended finite 
state machines (meaning they can have a data state as well as a control state, and 
communicate with the other state machines). The state transition diagrams for 
the packet generator and the subnets are straightforward — in the subnets of our 
current network model, the packets are just relayed at random to other output 
ports. However, the model is very flexible in this respect, so the functionality 
could also be changed such that the packets may be manipulated. 
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Fig. 3. STD for firewall FI 



For the behavioural model of the firewalls, as exemplified by the firewall FI, 
see Figure[^ Corresponding to each input port of the firewall (which models one 
of the interfaces of the firewall), there are a number of state transitions, cor- 
responding to forwarding rules of the firewallQAs an example, the highlighted 
transition DRule2 in Figure [31 can fire if a packet arrives at the interface fromDMZ 
connected to DMZ, with destination address Corporate, and with a service con- 
sistent with its source address. The correspondence is modelled by the function 
srvKons defined above. In case the transition fires, the packet is forwarded to 
the port toC, and the signal Present at the output port pass gives an indication 
that it was passed. The other transitions model other forwarding/dropping rules 
in an analogous way (FWRulel,2,3 for packets arriving from the FWAdmin subnet 
and CRulel,2 for packets arriving from the Corporate subnet). 

AutoFocus is based on a time-synchronous communication scheme, so an 
execution consists of a sequence of clock cyclesH Thus, the forwarded packet can 
be read by the connected components in the following clock cycle. In all, the 
highlighted rule corresponds to part of the firewall behaviour as specified in the 
previous section: packets from the Mail-, DNS-, or Web-Server to the Corporate 
subnet are only passed if the corresponding service entry is correct. 



2.3 Testing 

In our approach for firewall testing, we use the formal AutoFocus model as a 
specification to generate test cases. We call this specification-based test sequence 
generation (see e.g. [18]). For this purpose, first test case specifications based on 
the system model have to be formulated. Test case specifications would be, for 
example, that we look for executions where a packet arrives at a certain interface 
of a component, or executions where a packet is dropped by a firewall. These 
are translated into logic and solved. The solutions are all test cases of a given 

^ Note that often rules in firewalls are presented as sequences, and not as sets like 
here, but this makes no difference provided the rules are consistent. 

^ Note that this is not a restriction (even though we cannot assume a global clock in 
a network) because the actions specified here do not depend on global timing. 



Specification-Based Testing of Firewalls 313 



maximum length satisfying the test case specification. These test cases represent 
concrete system executions (which exact packets with which data originate at 
which component, the way they travel etc.), can be depicted as message sequence 
charts and fed into the actual implementation of the firewall system for testing. 

[TSj describes a test sequence generation approach based on a propositional 
solver (SATO), whereas in [13], a variant (also for AutoFocus) is presented 
that is based on constraint logic programming (CLP). We used the CLP variant 
for our purposes, as the CLP-solver proved to be more flexible with respect to 
specification and generation of the solutions. 

Thus, with our approach we can systematically generate many (or even all) 
test cases of a given maximum length to verify chosen security aspects of the 
firewall implementation. This leads to an improved reliability of the system re- 
sulting from the test, as opposed to ad-hoc testing. 

In general, our approach supports all kinds of test scenarios that can be 
specified based on the execution history of the system. Important test scenarios 
for threats against the firewall example system we tested include the following: 

— Stress test. For a chosen firewall component, generate all test cases from 
the specification, where this firewall drops an arriving packet. Thus, the 
firewall system to be tested can systematically be flooded with packets it 
should drop. 

As an example, for the firewall component FI we have to specify that a packet 
arrives at one of the input ports, but no pass indication is given in the next 
execution step. See Figured] for a corresponding MSC. This MSC shows the 
route of a packet coming from the Internet that arrives at the DMZ with 
destination address being the Mail server (so it is correctly passed on by F2), 
but is then incorrectly relayed to FI inside the DMZ — for example by a 
Trojan horse. 

— Spoofing. In this scenario, packets with forged source addresses are exposed 
to the system. For example, an attacker on the Internet may try to send 
packets to the Network that appear to have originated from internal hosts 
in the Network in order to defeat security mechanisms (such as the inner 
fire-walls) that rely on the source information of packets. These test cases 
can be generated in a similar way as above, by specifying that the packets 
generated by the PacketGen component should have forged source addresses. 
Spoofing is described in more detail in [2|. 

— Policy violations. As explained in |H], firewall systems have to be based on 
a security policy. In |S], this policy is given in the form that, if a packet was 
in a certain subnet, and reaches another subnet, a certain condition on its 
source and destination address and service has to be fulfilled. These policy 
statements can also be used for test sequence generation. Two variants are 
possible — first test case specifications which fulfill the policy rules and thus 
check if the firewall system correctly lets packets pass, and second test case 
specifications that violate the policy. The latter can be derived by negating 
the condition on the packet data and lead to test cases that check if the 
firewall correctly drops packets. The execution in Fig. jjjactually represents 
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both a test case for fulfilment of the policy given in section ET|(smtp packets 
from the Internet to the mail server can be passed to the DMZ) and a 
violation (those packets must not be relayed on to the Corporate or FWAdmin) 
subnets. 

Systematic Selection of Test Sequences. For a given test case specifica- 
tion, the number of test cases can get fairly large — especially with more complex 
data types than in our example. In our case, we can use domain-specific knowl- 
edge to improve coverage. Firstly, the maximum length of the test sequences can 
be restricted to the diameter of the network, provided that only one packet at a 
time is considered and the components do not maintain states. In addition, we 
can separately generate a number of test cases with fixed packet origin, source 
address, destination address or service specified in addition to the original test 
case specification, to ensure these possibilities are tested. In a further stage, this 
is also possible for certain combinations of these parameters (e.g., tests where 
packets originating from the Internet with service “Smtp” are involved etc.). 

Performance. Computing test cases of the above kind for our example net- 
work takes about .Is per test case, measured on a SUN UltraSparc with 1GB of 
main memory running at 400MHz. 



3 Related Work 

introduces a language for expressing global network access control policies 
and algorithms to compute filters for such policies and to check filters against 
policy violations. Enu present a firewall management toolkit. Contrary to ours, 
the intention of this work is not firewall testing, but managing the configuration, 
and it is assumed that all filtering devices work properly m p.2]. [Tg uses 
model-checking to analyse network vulnerabilities. 

A Petri-net model of firewalls is given in m- References to work on specifica- 
tion-based testing are in m- The Focus method underlying AutoFocus has 
previously been used for systems security, e. g. in nnnii. 
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4 Conclusion and Future Work 

We proposed a method for specification-based testing of firewalls, enabling one 
to formally model the firewall and the surrounding network and to mechani- 
cally derive test-cases checking the firewall for vulnerabilities. We used a general 
CASE-tool which makes our method flexible and easy to use. We demonstrated 
our approach with an example firewall. 

In future work we will consider advanced network and firewall designs, such 
as authentication headers (using cryptography), virtual private networks, and 
distributed firewalls. It would be desirable to have a higher-level language for 
the security policies that is automatically translated into rules (following jH]). 

Also, our approach opens up the possibility to go beyond test-sequence gener- 
ation and perform the actual testing automatically, on an actual firewall system. 

Acknowledgement. Helpful comments by Joshua D. Guttman on a draft are 
gratefully acknowledged. Many thanks also go to Alexander Pretschner for help- 
ful suggestions on constraint-based test sequence generation and comments on 
this paper, and to Heiko Lotzbeyer for the implementation work. 
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Abstract. We argue that there is a gap between software engineering 
cultivated in the universities and industrial software development. We 
believe that it is possible to get academia and industry closer by starting 
projects that will require solution of non-trivial scientific tasks from one 
side and long-term commitment to create a product out of this research 
solutions from the other side. We illustrate our position on a real-world 
example of collaboration between an American company Relativity Tech- 
nologies and research teams from St. Petersburg and Novosibirk State 
Universities. We also point out that the current economic situation in 
Russia presents unique opportunity for international projects. 



Introduction 

Industrial programming is usually associated with big teams of programmers, 
strict timelines and established solutions and technologies. On the other hand, 
the main goal of academic research is to find new solutions and break existing 
stereotypes. Unfortunately, amazingly low percentage of scientific results makes 
their way into practice, and even when they do, the process is very slow. 

In the meantime, practice always required a solution of the tasks that are 
infeasible from the point of view of the existing theory. Today this common truth 
takes on special significance for software engineering because the number of its 
applications really exploded. A special emphasis on this problem was made by 
academician A.P. Ershov. By the way, it is little known that for several years 
A.P. Ershov worked as a consultant in research institute “Zvezda” of LNPO 
“Krasnaya Zarya” (Leningrad). By tradition of those times this job was not pa- 
raded, because the institute worked in the area of government communications, 
so later on even specialists who knew A.P. Ershov personally, were surprised 
that a scientist so famous was spending his time on such “utilitarian” problems. 

It is a well-known situation when practitioner is posing a problem and the- 
oretician is reasoning why this task is unlikely to be solved. But the proof of 
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impossibility of correct solution of the problem does not satisfy the demand for 
it, so practitioners start to seek partial or heuristic solutions or try to use “brute 
force” method. 

In this article we try to show that even on this shaky ground it is better 
to use specialists that know the theoretical restrictions, complexity estimations 
for this or that solutions, optimization methods and other traditionally scientific 
knowledge. This sounds pretty obvious, but somehow the chasm between aca- 
demic and scientific communities is very difficult to close. What are the main 
reasons for this? 

It is well-known that software engineering is differing from pure mathematics 
or even computer science. Proved theorem or complexity estimation for some 
algorithm are results by themselves, and there are no other requirements for 
their creation other than scientists’ talent, pen and paper. On the other hand, in 
software engineering a new interesting approach or even working prototype does 
not guarantee that they will lead to the successful and ready-to-use product. To 
achieve this, one should add up large teams, investments and strict industrial 
discipline. In this respect, software engineering is close to elementary-particles 
physics or physics of ultralow temperature etc. 

Nevertheless, there are some positive examples and we believe that they 
could be considered as role-models for promoting collaboration between industry 
and science. We try to illustrate this process on the example of creating an 
automated reengineering tool RescueWare, which automates reengineering of 
legacy software, i.e., conversion of systems written in COBOL, CICS, embedded 
SQL, BMS, PL/I, ADABAS Natural and other languages, working mostly on 
IBM mainframes to C-|— k, VB or Java. Software reengineering does not end up in 
simple translation from one language to another — completlely different schemes 
of dialog with the user, access to legacy databases, recovery of lost knowledge 
about the program make this task much more difficult. 

This project was carried out by large international team, which was geograph- 
ically spread from North Carolina (USA) to St. Petersburg and Novosibirsk. The 
customer for this project was an American company Relativity Technologies, and 
the team that worked on this project included scientists from St. -Petersburg and 
Novosibirsk universities, LANIT-TERCOM company and A. P. Ershov Institute 
of Informatics Systems of Siberian Branch of Russian Academy of Sciences. The 
total investment in this system amounts to more than 400 man-years. 

Our collaboration began in 1991, and during these years we have overcome a 
lot of difficulties, mostly related to cultural difference and lack of understanding. 
Finally, as a result of common efforts we created a science intensive product Res- 
cueWare Workbench, which was recognized by Gartner Group as a best product 
in 2000 in the area of legacy understanding. In the following sections we give a 
detailed descriptions of the hard problems that we had to solve in order to make 
this project a success. 
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1 Architecture for Multi-language Support 

From the very beginning we were oriented on creation of multi-language trans- 
lator, so one of our first tasks was to design a unified intermediate language (IL) 
for our system. The idea is that program transformation is two-staged: at first 
the program is converted to IL, and then to the target language. When there 
are M input and N output languages, this approach makes it possible to limit 
the amount of work to M -\- N compilers instead of M * N. 

Under the name of UNCOL this approach is known for more than 30 years. 
A lot of teams were trying to implement it, but only a few managed to create 
something tangible m- Now what is the problem? From the theoretical point of 
view, all langugages are computationally equivalent, and thus conversion should 
be quite simple. The difficulties arise when we are measuring the quality of out- 
put program not only from the point of view of its performance, but mostly from 
the point of view of naturality of program’s structure in this or that language. 

Every programming language gives us some means of expression and a disci- 
pline of using them. At that, the most quality from the point of view of quality 
and easiness of maintenace could be attributed to those programs that meet the 
requirements of this discipline. 

The problem appears when notion of “natural program” in one language 
contradicts with the same notion in other language. For instance, using GOTO 
statements is usual for COBOL, but in Java there are no such statements at 
all. Some special and sometimes non-trivial transformations, dependent both on 
initial and target platforms, may be required to solve this problem. 

Let us name the main levels of program representation: 

1. Control flow representation 

2. Data flow representation 

3. Representation of values 

Thus IL must contain abstract means for program representation at all these 
levels, and the transformation will look as follows: first language constructs of 
the source language are “raised” to abstract intermediate representation and 
then they are “lowered” to concrete representation in the target language. The 
degree of abstraction should be carefully chosen to make sure that this lowering 
down leads to natural projections to the target language. 

The most important condition for the proposed approach is the orthogonality 
of translations to IL and from it. This means that the representation of source 
program in IL should not depend on the target language. 

Finally, IL should be extendable, i.e., it should contain features that permit 
to build new constructs without changes to all existing passes of compiler. 

The weak point during IL design is the choice of data types and standard 
opertions. While the set of control constructs in different languages is more or less 
suitable for unification, data types system could be significantly different. It is 
inexpedient to simply combine all types of the source languages, because addition 
of new language will require major changes to existing compiler functionality. 
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To solve this problem, it is important to add not only standard data types 
to IL, but also add formalism of higher order — type constructor — which 
could be regarded as a function, which produces a new type out of several given 
types. For example, abstractions such as structures, arrays and pointers could 
be considered as type constructors. Indeed, the structure could be defined as 
a type constructor, which receives a set of field types and creates a structured 
types with the fields of corresponding types. 

Finally, usage of type constructors eases runtime support, for we can consider 
type constructor, which is treated as an abstract dynamic data type and could 
be used only through runtime support functions. This ensures that the addition 
of a new entity requires changes in only one compiler pass — namely, of the pass, 
which creates this entity. After that all handling of this entity will be transparent 
to the compiler and conducted through conversion of type constructors. 

We believe that this task presents a good example of semantic gap between 
academic research and industrial programming. The idea of unified IL makes 
sense only in large-scale projects, and these projects are out of acaedimic scope. 
On the other hand, average programmer in the industry just does not possess all 
the knowledge, which is required for successful implementation of this approach. 

Note that “naturality” of IL structure, which was mentioned above, is also a 
good example of difficult to formalize notions. These notions are often necessary 
to solve usual everyday tasks. Another example of difficult to formalize notions 
is the definition of “good program” criteria [^. 

2 Re-modularization. Class Builder 

Another interesting task that we encountered during creation of automated 
reengineering tool is re-modularization of programs into components |4I5| . 

This task could be described as follows: there is a large application that con- 
sists of multiple files, which contain declaration of data and procedures. Variables 
and procedures from different files are interacting with each other through some 
external objects, which we called dataports. For legacy systems usual dataports 
are CICS statements, embedded SQL and other infrastructure elements. 

This task was formalized as follows: application was represented as a graph 
with application objects as junctions of various types (variable, procedure or 
external object), and relations between them as graph edges. Edges are also 
typed (for instance, procedure call, variable usage in procedure, working with 
external object through variable etc.). Also, each edge is attributed with some 
number, which defines the “power” of this relation. For example, the power for 
procedure call relation could be defined by the number of parameters passed: 
the more parameters we have, the more we want to place both callee and caller 
to one component. 

This graph should be divided into some areas of strong connectivity. To do 
this, we introduce the notion of gravity between two nodes, which is calculated 
as sum of powers of all edges connecting them multiplied to coefficient defined 
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by the edge type, minus some constant, which is defined by the pair of edge 
types. 

Some negative part of the formula — the repulsive force — should be in- 
cluded, otherwise we will always get one monolith. For instance, it seems natu- 
ral to add repulsive forces between dataports and any procedures. This way we 
want to separate all procedures first and only when two procedures are using 
too many common variables, then the gravity force prevails. 

Then by complete enumeration we find those junction sets, for which the 
sum of gravity force between themselves and the junctions from other sets are 
maximal (of course, gravity forces with the junctions of other groups are taken 
with minus sign). 

It is clear that this good idea will not work in real life, because the number of 
graph junctions in real applications is way too much to use exhaustive searches. 
But we managed to find some heuristic approaches, which made it possible to 
achieve practical results. 

First of all, we fixed some coefficients for different types of edges and repulsive 
forces for different types of junctions. However, the user can assign coefficients 
on his own if he believes this to be of importance for his application. 

Secondly, in the complete graph of application we will start with sub-graph, 
which consists of the junctions corresponding to external object plus edges and 
junctions of any other types, which connect these external objects. The heuristics 
is that we believe external objects to be cross-linking and thus we add repulsive 
forces only for them. On the other hand, if two external objects are using a lot 
of common variables and procedures, then nothing prevents them from ending 
up in one component. 

Thirdly, we will regard all edges of reduced graph as being of the same type, 
but we will define the power of each edge so that the more relations there are 
(not only direct, but also transitive ones), the bigger is power. To formalize this 
notion of “bigger” , we will use the physical model. 

To calculate the power of edges in reduced graph we proposed to use the 
model of electric mains. In this model we will consider that there exists a wire 
between any two junctions of the input graph that have a positive gravity force 
between them and we will equal this force to the conductivity of the wire (let us 
remind that conductivity is the reverse function of resistance) . Then as a power 
of edge between two junctions of the reduced graph we can use the complete 
conductivity of the electrical network between them. The complete conductivity 
could be calculated using Kirhgof equations, so we need to solve a set of linear 
equations. The complexity of this task is equal to finding the inverse matrix. 

3 Program Slicing 

Let us suppose that a legacy system performs ten functions, seven of which are no 
longer needed, but the remaining three are in active use, and as it often happens 
with legacy programs, nobody knows how these three functions work. In this 
case it is necessary to create a tool for deep analysis of the old programs, which 
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can help maintenance engineer to find and pick out the required functionality, 
put the corresponding parts of the program into a separate module and reuse it 
in the future, for instance, to move it to modern language platform. 

The solution of this task is based on creating static slices of the program 
and their modifications. We regard program slices to be a subset of program 
statements that presents the same execution context as the whole program. Slice 
is a program that contains the given statement and some other statements of 
the initial program, namely those that are related to this statement. 

The following methods are implemented in Rescue Ware for automation of 
business rule extraction (BRE): 

— Computational-based BRE 

— Domain-oriented BRE 

— Structure-oriented BRE 

— Global BRE 

All these methods assume generation of syntactically correct independent 
programs that preserve the semantics of the original code fragments. 

Computational-based BRE forms the functional slice of the program, based 
upon the execution path and data definitions that are required to calculate the 
values of the given variable in the certain point of the program 0 ). 

Domain-oriented BRE generates functional slice of the program, which is re- 
ceived by fixing the value of one of the input variables. Being based on theory 
of program specialization, domain-oriented BRE is best suited to separate cal- 
culations with many transactions and mixed input, into a series of “narrowly 
specialized” business rules with only one transaction for each of them. 

Structure-oriented BRE makes it possible to divide the programs written as 
a single monolith into several independent business rules, based on the physical 
structure of the initial program. Also, an additional program is generated that 
calls the extracted slices in a proper sequence and using the correct parameters 
(ensuring the semantic equivalence of this program to the initial one). This 
method is best suited to divide old large programs into parts that are easier to 
handle. 

Finally, global BRE helps to apply all of the methods mentioned above to 
a number of programs simultaneously, and thus supports BRE on system-wide 
basis. 

Notwithstanding all automation, the choice of slicing points in the program 
and the sequence of application of different BRE methods are left to the hu- 
man analytic, which decomposes the initial system. There are several natural 
points to start applying BRE, for instance, the places where the calculated val- 
ues are stored to the database or printed to screen. Of course, intelligent choice 
of candidates for business rules requires knowledge about functions of the initial 
system. 

On closer examination it often turns out that the methods used are differing 
from one module to another. Moreover, it is sometimes useful to apply different 
BRE methods subsequently to the same program. 
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4 Conclusion 

As of right now, products such as RescueWare are not really typical for the 
market, because creation of RescueWare required solution of many scientifically 
difficult problems. Let us briefly mention other achievements: relaxed parser that 
ensures collection of useful information even for quite distant dialects of the 
language, different variants of data flow analysis, using sophisticated algorithms 
of pattern matching for identification of structure fields in PL/I etc. 

Of course, not all projects require investment of this amount of research. Even 
in our own practice not all projects both in Russia and USA were so rewarding. 
Our present understanding of importance of education and training in software 
engineering came only after a lot of painful experience. The contacts with the 
universities are important for the industry not only because of the talent pool 
accumulated there, but also because of new ideas and scientiflc breakthroughs 
that can make the sofware product a success. This road is very difficult; some- 
times the scientiflc research contradicts with the strict timelines and discipline, 
but the potential payoff of this approach is immense. 

Finally, we would like to emphasize that Russia is in a special position to 
make this vision come true, because it has an undoubted advantage in the level 
of education at the software market. We hope that our experience of successful 
cooperation of American company with Russian scientists could serve as a good 
example for many Western companies. 
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Abstract. This paper proposes a method for recovery and subsequent 
maintenance of the architecture for actively evolving software systems. 
The method’s underlying idea has to do with constructing a basic set 
of the architecture elements, which set would then be used for creating 
different views of the system. The responsibilities of the modules, which 
make up the software system, as well as elements of the system’s data 
dictionary, are considered elements of this basic set. Of special meaning 
is the fact that the system is being actively maintained and developed, 
that the knowledge about it is accessible, but needs to be alienated from 
the respective bearing media, to be generalized and formalized. 



1 Introduction 

While many software products, for which the architecture was never formalized, 
may exist for years and be successfully maintained, still one can face a situation 
when formalization of the system architecture becomes a priority task. As a 
result, a lot of architectural imperfections in the system reveal themselves, and so 
there comes such moment in the life of the product, when its further development 
is impossible without improving the architecture, which requires formalizing the 
latter. Even various methods of analyzing and designing software systems have 
been spreading widely [TT MTUI , it is a greate problem to use such methods in 
the situation like this. On the one hand this activity can cause serious internal 
restructuring of the system. On the other, we cannot ignore the commercial 
aspects of the software development process, issuing of new versions, service 
packs, and the implementation of new customer’s requests. 

Thus there is a problem: how to perform reverse engineering of the architec- 
ture of the actively evolving system, with most effective gathering and formali- 
sation of the meta-information on the system. In the same time the architecture 
views should be supported in actual while the system will evolve. There are many 
methods and tools of reverse engeeniring designed for recovering the knowledge 
about a system architecture based on source code parsing (Refine/ C, Imagix 
4D, Rigi, Sniff |6I9| |. RescueWare). Also there are formal methods of the reverse 
engineering [3j . 
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All these methods have the same week point: absence of mechanism for syn- 
chronization of the model recovered with the source code of the software system. 
This problem makes very ineffective the use of such methods for actively evolv- 
ing systems. From this point of view, there are more perspective Use-case driven 
methods |4], because the models that were derived with this method should be 
more stable to the system’s changes on the practice. Data-mining methods 0, 
relying on the inner links between system elements are also interesting from the 
same viewpoint. However, all these methods are more suitable for the architec- 
ture of the “dead” system. 

Round-Trip development methods, that are provided with some CASE- 
packages (e.g. Rational Rose, Together), enables the bi-directional connection of 
source codes and the architecture view. But the quality of the information visu- 
alized is unsatisfactory, because in fact, we do not get any new meta-information 
on the system, but only visualize the source code structure. 

2 Starting Point 

Let’s formulate the basic problems that are to be solved with the presented 
method of architecture recovery: 

1. The utilization of the features of the “living” system for the most effective 
architecture recovery; 

2. The ability of the maintenance and further development of the architecture 
view of the software system; 

3. The ability of step-by-step adopting of the process of development and sup- 
port of the architecture without any serious damage to industrial require- 
ments to the process. 

3 The Method 

3.1 Structure of the Model 

The system architecture model proposed with this method consists of the fol- 
lowing views: Structure views. Dynamic views and Physical view. 

The basis of describing the system architecture is a System Structure descrip- 
tion, which it is proposed to implement on the physical level (Physical view) and 
the logical level (Structure views). The Dynamic views are needed in order to 
determine the main scenarios of the system’s operation. 

The necessity of different kinds of views of the software is well known mm- 
With the method in discussion, it is proposed to construct also a set of various 
Structure and Dynamic views, which is motivated by the following considera- 
tions: 

1. The participants of the project, whose positions are on different levels of the 
hierarchy (managers of different levels) need information about the system 
to be specially adapted; 
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2. There exist both a vertical division of the system (by business functions) 
and a horizontal one (by tiers - e. g., User Interface, Business-Logic, Data 
Access); 

3. There are different modes of packaging and deployment of the system; 

4. In order to compile the entire project, information about the structure of 
storing the source codes of the system is needed; 

5. Organizational structure of the enterprise affects decomposition of the sys- 
tem. 

Structure Views. It is proposed to organize Structure views in the form of 
UML class diagrams. We herewith associate some part of the system (subsystem) 
with a class. The subsystems are organized into a multiple containment hierar- 
chy, with the only restriction that the aggregated subsystems become invisible 
from the context, in which their aggregate exists. The different views should be 
constructed upon the same basic set of subsystems, but in other respects do 
not require any special matching. Associations between the subsystems, which 
reflect their semantic connections, are possible on each level. 

Dynamic Views. With the help of the dynamic views it is proposed to 
represent the main scenarios of the system’s operation. One can associate with 
each level of a structure view a dynamic view, which would explain how the 
subsystems interact with each other. For this, it is proposed to use the UML 
Collaboration Diagrams. 

Physical View. This view is designed for inventory of the software source 
codes and for associating them with elements of the structure and dynamic views. 
In the view, the following items are considered: 

1. Set of program modules (e. g., for Microsoft Visual C-|— I- these are projects); 

2. System data dictionary, which consists of: 

a) Persistent data (logical data of the system and the corresponding phys- 
ical media); 

b) Channel data, with which subsystems exchange not through persistent- 
structures (physically media are absent, only logical elements of the data 
are there); 

c) Configuration data that constitute a kind of persistent data, but are 
responsible for tuning the system algorithms (logical data and the cor- 
responding physical, media). 

3.2 Constructing the Basic Set 

The foundation of this method consists in constructing a basic set of subsys- 
tems, from which different structure views will be built. In order to keep the 
correspondence of the views to each other and to make the maintenance easier, 
all elements of such views are to be subsets of the basic set of subsystems. So, 
the views themselves are hierarchical coverages of the basic set: the elements 
of each view form an aggregation hierarchy and the set of leaf nodes in that 
hierarchy is a usual coverage of the basic set. The basic set is constructed from 
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responsibilities, which are assigned to the system modules (3-5 responsibilities 
per each module) and with elements of the system data dictionary. 

Elements of the basic set of subsystems may be included in subsystems of 
different views; therefore, for them multiple containment is permissible. 

When construction of the basic set is finished, all participants of the devel- 
opment process may build for themselves a package of structure and dynamic 
views that they need. A coordination of different views is provided by due to 
integrity of the set of basic elements, which are placed on different diagrams. 

4 Conclusions and Further Research 

The method presented is designed for recovery, formalization and further main- 
tenance of architecture of the actively evolving software systems. 

At the moment there are some open problems to focus the investigation on. 
These problems are mainly about the adoption of the method presented in the 
industrial process of software development: 

1. Clear mapping of the presented method’s notions to UML; 

2. Organization procedure of the adoption of the method presented. 
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Abstract. The paper describes evaluation results of some modern re- 
targetable codegeneration frameworks. The evaluation was performed to 
estimate applicability of these approaches in hardware-software codesign 
domain so ease of retargetability and efficiency of generated code were 
main criteria. Evaluated tools were selected from National Compiler In- 
frastructure (NCI) project. 



1 Introduction 

Hardware-software codesign is modern technique aimed to obtain high produc- 
tivity of real-time and embedded systems. Key feature of this approach is simul- 
taneous development of the program and the target processor or specialization 
of parameterized processor architecture to match target software application. 

Generally, codesign implies iterative development. Each iteration consists of 
building new hardware description based on previous profiling and efficiency 
estimations, building (somehow) compiler, debugger, simulator, compiling and 
possible debugging target application, profiling and estimation of profit/loss. So 
building set of retargetable tools is basic and very frequent procedure. 

Despite a number of retargetability techniques building of compiler still re- 
mains matter of art. Since main codegeneration approaches are investigated well 
the contiguous tasks (supporting of calling and linking conventions, building de- 
bugger and profiler etc.) should be solved (semi)-manually. The most crucial 
problem of building machine-dependent code optimizer also remains open. 

Here we describe most recent retargetable codegeneration frameworks that 
look most preferable for purposes under considerations and briefly present the 
results of their evaluation (see [4] for details). 

2 Retargetability Issues 

Compiler’s retargetability is usually understood as its ability to be re-targeted 
to another machine platform “automatically” or ’’nearly automatically”. This 
implies building of codegenerator from some description. Ideally such a descrip- 
tion should be extracted from description of actual hardware but as for now 
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there is well-known semantic gap between hardware description and codegener- 
ator description. So now transition from hardware to codegenerator is mainly 
proceeds as follows: first verbal instruction set description is produced, then 
codegenerator description is written from it. 

Starting from the most fundamental results in code generation area |1I3| main 
retargetability technique stays tree pattern matching and dynamic programming. 
A number of ways to exploit this idea are investigated I6I7I13I24I25I : also there 
are a number of compilers based on them. These methods often considered as 
means of instruction selection so register allocation and instruction scheduling 
should be done separately. 

Similar attribute-grammar based method described in m- Most of heuristic 
codegenerators use this notion. 

Quite different approach suitable for VLIW processors codegeneration is sug- 
gested in [ISEO]. This approach is based on covering of so-called split-node DAG 
that reflects possibilities of parallel execution of DAG nodes with primitive in- 
structions — so instruction selection, resigter allocation and scheduling are all 
performed simultaneously. To provide feasible schedule binate eovering method 
is used HZEO!. Unfortunally there is no compiler built on this technology so 
there is nothing to evaluate yet. 

Finally there are some novel approaches to retargetable codegeneration in- 
cluding automatic building of codegenerator from architecture or instruction set 
description [11)123131 j . However tools presented there are either far from real 
industrial compilers or not accessible for evaluation. 



3 Criteria and Methods 

The basic factors to be taken into account are, of course, quality of generated 
code and ease of retargetability. 

To assess quality of generated code, we compare the performance of several 
benchmarks on architectures that the tools being evaluated are already ported. 
We use Intel Pentium III and Sun SPARC processors for this purpose. 

We used benchmarks developed by Standard Performance Evaluation Corpo- 
ration (SPECjB This is an industry-standard set of benchmarks to assess quality 
of computer systems. However SPEC was not initially designed to be used as 
tool for compilers’ performance comparison. For example it contains benchmarks 
written in different programming languages (Fortran, C-|— 1-, C) and moreover 
utilized some specific compiler-dependent features. So we changed some SPEC 
benchmarks to make them appropriate for other compilers being evaluated. 

Then it turned out that some of compilers were unable to compile some 
SPEC tests correctly either at whole or with some optimizations turned on. So 
we provide some auxilliary narrow set of benchmarks beyond basic SPEC set. 
These benchmarks are: 
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— bzip2: BWT-based data compression utility, by Julian Seward 

— gzip: LZW-based data compressor, by Jean-Loup Gailly 

— ranking: Implementation of Symbol Ranking text compression algorithm, by 
Dmitry Lomov 

All of these benchmarks were compiled by all of evaluated tools with major 
optimizations turned on. 

In according to reasons mentioned above we evaluated all tools in according 
with measures listed below: 

— Soundness: describes how close evaluated tool is to real industry compiler. 
We express soundness in percents of all passed SPEC benchmarks. 

— Selected Performance: describes peak compiler performance. To evaluate se- 
lected performance we compared compilers on narrow set of benchmarks. 
We express selected performance using formula K/ absolute running time, 
where K is some specially selected constant. 

— Overall Performance: describes performance evaluated on full SPEC suite. 
In addition we use non-retargetable platform-native compiler for comparison 
purposes. Overall performance expressed in percents of best performance 
among all tools 

Informally speaking, selected performance reflects some expectations about 
compiler’s performance after all bugs eliminated. Note that this estimation is 
rather optimistic because fast code can probably be generated due to inaccurate 
analysis during optimizations. 

To assess ease of retargetability, each tool evaluated has been ported to a 
“toy” instruction set, designed for a specific algorithm. Symbol Ranking was 
choosen as target algorithm. This estimation is also optimistic because it is 
much simpler to port compiler for special fixed application. 

4 Evaluated Tools 

We selected compilers from National Compiler Infrastructure (NClj^ project. 
The project was started under support of DARPA and NSF by major USA 
Universities (Harvard, Princeton, Stanford, Rice etc.) 

On the other hand we have chosen legendary gcc compiler [30] as most 
authoritative industrial optimizing C compiler. 

NCI project is aimed at developing interoperable framework for constructing 
retargetable, optimizing compilers. Combination of these two qualities - retar- 
getability and optimization - is crucial for hardware-software codesign. Without 
good retargetability, co-design cycle becomes unbearably long; without optimiza- 
tion, the whole idea of co-design is compromised, as non-optimizing compiler does 
not employ features of the target architecture to its best. NCI project compilers 
represent current state-of-the-art in developing easily retargetable, optimizing 
compilers. 

http: / /www. cs.virginia.edu / nci / 
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Currently three C compilers are available from NCI: SUIF/MachSUIF, Icc 
and VPO-based compiler. We evaluated all of them. 



SUIF and MachSUIF. SUIF (Stanford University Intermediate Format) [TR] 
and MachSUIF (Machine SUIF) |2S] are developed in Stanford and Harvard 
Universities correspondingly. Both systems are parts of NCI project. Unfor- 
tunately SUIF /MachSUIF compiler is not ported to Sun SPARC so it is not 
evaluated at that platform. 

VPO-based compiler. VPD (Very Portable Optimizer) is a part of Zephy0 
project. The project is in turn part of NCI. 

Icc compiler. Icc compiler was developed in Princeton University, USA, since 
1991 and later was also involved into NCI project 



gum III 



5 Results and Conclusions 

Unfortunately at the time of writing the paper only selected performance eval- 
uation was completed on Sun SPARC platform. The result of the evaluation is 
shown at figure [T| The other results are to appear at 
http://oops.tepkom.ru/eval.html in near future. 
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Fig. 1. Selected performance on Sun SPARC, 1000/absolute time 



Results of soudness evaluation on Intel Pentium III platform are shown at 
figure [3 We can conclude that neither SUIF nor VPD turned out to be ready-to- 
use compilers — during the evaluation we encountered lots of bugs that had to 
be fixed. 

http: / /www. cs.virginia.edu / zephyr 
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Fig. 2. Soundness on Intel Pentium III, % of passed benchmarks 
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Fig. 3. Selected Performance on Intel Pentium III, 1000/absolute time 
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Fig. 4. Overall Performance on Intel Pentium III, % of best performance 
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Selected and overall performance evaluation results at Intel Pentuim III are 
shown at figure |3] and figure |H correspondingly. We have choosen Intel C/C++ 
compiler (icc) as non-retargetable platform-native compiler. 

Our benchmarks show that SUIF/MachSUIF compiler is competely unapplica- 
ble for producing efficient code. This is largerly due to inappropriate instruction 
selection techniques and lack of optimizations. 

Regarding the efficiency of generated code, we saw that generally gcc with op- 
timizations on beats all the other retargetable tools. If optimizations are turned 
off in all tools, Icc shows best performance. VPO has shown quite irregular per- 
formance — on some benchmarks it produces the best code of all, while on others 
it lose even to non-optimizing Icc compiler. 

However as a result of auxilliary testing we discovered “contradictionary” 
benchmarks that are not fit into conclusion given above: 

1. Icc beats all retargetable tools on Objective Caml0 garbage collector im- 
plementation (30% better than gcc) on Intel Pentium III 

2. VPO beats all retargetable tools on certain implementation of Symbol Rank- 
ing text compression algorithm (5 times better than gcc) on Sun SPARC 

Finally we can see that platform-specific Intel compiler outperforms all re- 
targetable tools. 

As the ease of retargeting, Icc turned out to be the best of all considered 
tools, gcc and VPO on the whole show same level of retargetability, although 
gcc is much better documented. SUIF/MachSUIF is less retargetable because it 
is necessary to rewrite codegenerator manually to retarget it. 

We conclude that none of the methods considered allows to build a retar- 
getable code generator that can directly be utilized for co-design purposes. 

We also see the importance of instruction selection — Icc, a non-optimizing 
compiler with good instruction selection algorithm based on BURS I3I7I13I241 
1251 shows quite good performance. 

However, good instruction selection is not enough for obtaining optimized 
code. VPO outperforms Icc on majority of tests. 

This research shows the directions for further development in co-design and 
code generation area. Easily retargetable, optimizing compilers are vital for 
hardware-software co-design, but we see that techniques for building them are 
yet to be created. 
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Abstract. Conceptual modeling of a system consists of giving a 
structured form of information in a way it captures, as much as possible, 
the semantics of real word objects. The most popular conceptual model 
for designing operational databases is the Entity -Relationship (ER) 
model. This model has evolved into models for designing object-oriented 
system in general. However, despite some formalization attempts, most 
conceptual techniques remain rather informal. Our aim in this paper is 
to provide a formal algebraic methodology for conceptual modeling. In 
the paper we apply our methodology to ER-model but we claim that it 
is applicable for object modeling with a slight modification. We believe 
that our approach can help designers in schema validation. 

Keywords: algebraic semantics, algebraic specification, conceptual 
model, meta-modeling. 



1 Introduction 

The most widely-used conceptual model for designing an operational database 
is the Entity Relationship model, or ER-model, originally introduced by Chen [^. 
The main generic concepts of this model are entity type, relationship type, at- 
tribute and eonstraint. An entity type represents a set of real-world objects and 
a relationship type relates two or several entity types. A property of an entity 
(or a relationship) type is called an attribute. Each attribute, entity type, or 
relationship type is recognized by a unique identifier called its name. Roughly 
speaking the conceptual schema of an application is the collection of these in- 
ter related names. In order to capture more semantics of real-world objects and 
their relationships, those names are enriched with some constraint declarations. 
A suitable choice of those names and constraints give us information about the 
nature (or the semantics) of the application. In general setting, constraints are 
logical formula about entities, relationships and attributes. The most widely-used 
constraints are domain constraint, key constraint and cardinality constraint. A 
domain constraint concerns an attribute, it specifies the type of that attribute. 
An attribute can have a simple type, a record type, or a collection (i.e. a set, a 
bag or a list) type. A key constraint concerns one entity type and its attributes. 
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A cardinality constraint concerns an entity type and a relationship type in which 
that entity type participates. In ER-literature, other kind of constraints have been 
proposed which concern several relationships types and several entity types. At- 
tributes, entity types, relationship types and constraints provide a specification 
of the application, representing its conceptual level. Several approaches have 
been proposed for representing this specification graphically. Such a graphical 
representation is called an EK- diagram. There is often a confusion between the 
schema itself and its ER-diagram. One of the most important steps of designing 
an operational database is to determine its EE- diagram. A CASE (Computer Aided 
Software Design) tool helps to draw an ER-diagram and generate automatically 
an operational database scherngQ. Real world objects of an application at a mo- 
ment of time may be viewed as the physieal level of the application. It forms a 
valid instance of the ER-diagram. In the majority of proposed approaches, the 
border between conceptual and physical levels is blurred. This paper proposes an 
algebraic framework tracing this border neatly. To do this, we define formally, 
by operations and axioms, the conceptual level called ER-schema. Axioms are 
algebraic counter parts of constraints, and a valid instance is a finite model of 
these operations and axioms. To define formally the physical level, we interpret 
each attribute by a set of values called its domain and then we naturally extend 
this interpretation to entity types and relationship types. Note that the domain 
of an attribute in this approach can be a set of any kind of values, i.e., atomic 
values, collection values or tuples (records). This separation of conceptual and 
physical level aligns our approach with classical algebraic specification of data 
types. Following traditional algebraic approaches, the class of all valid instances 
of a schema is called its “loose semantics”. Moreover, we prove that the design 
process itself can be structured as a schema — the meta-schema — such that 
the loose semantics of the meta-schema is the class of all well-formed schemas. 
In a practical point of view the implementation of the meta-schema can help 
designers in schema validation. 

The remainder of the paper is organized as follows. Section |5]briefly describes 
the basic mathematical background and develops (max, min) -cardinality in a 
general and formal way. Section El introduces our formal definition of an ER- 
schema and compares it with classical approaches. We show how a schema can 
be seen as an algebra of a specification. SectionlH introduces an instance of such 
a schema in the style of denotational semantics. Section El explores a particular 
schema called the meta-schema, and proves that each valid instance of the meta- 
schema is an ER-schema in our sense. Section El briefly compares our results 
with some related works and draws a brief conclusion and indications to further 
research. Proofs of facts and theorem have been simply sketched. 



2 Constraints 

For a partial function f : X ^ Y we call X its source and Y its target, and we 
denote by def{f) its definition domain. The function / is called: 

^ For example, POWER PC (a Sybase product) transforms an ER-diagram into a rela- 
tional schema coded in SQL. 
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— finite iff the definition domain of / is a finite set, 

— total iff def{f) = X, and surjective iff f{def{f)) = Y, 

For two finite functions with the same source, f : X ^ Y and g : X ^ Z, we 
say: 

— / and g are exclusive, denoted / fl g = 0, iff def{f) fl def{g) — 0, 

— / and g cover Xx C X , denoted f U g = Xi, iS def{f) U def{g) = Xi, 

— / is less defined than g, denoted f Q g, iS f{x) = g{x) for all x € def{f). 

It is self evident that the problem of checking each of above constraints for finite 
partial functions is a decidable problem. 

Let nat be the set of nonnegative integers and uj = nat U {IV}, where N 
is a symbol not in nat. We extend the usual order of nat to lo hy n < N for 
all n G nat. Ordered pairs (0, k) and (fc, N) are said to be basic cardinalities if 
k G nat. For instance, the classical (min, max) -cardinalities (0,1), (0,iV) and 
(1, N) are basic. Now, we specify two binary operations A and V and we define 
the set CARD of all cardinalities as follows: 

— every basic cardinality is a cardinality, and 

— if Cl and C 2 are cardinalities, then so are ci A C 2 and ci V C 2 . 

The semantics of each cardinality c, denoted |c], is defined as follows: 

1(0, 0)1 = 0; 

1(0, k)l = {x \ X < k} , where fc > 0; 

l(k, iV)] = {x \ k < X and x N}, where fc > 0; 

|ci A C 2 ] = |ci] n |c 2 l; 

|ci V C 2 ] = |ci] U |C21. 

As a result, reZazed cardinality and int- cardinality constraints (following |T2], [S]), 
are cardinalities in our sense. In particular, the classical cardinality (1,1) is the 
cardinality (0, 1) A (1, N), and for any a and b in nat such that 0 < a < b < N, 
the interval cardinality (a, b) is the expression (a, N) A (0, b). But our cardinality 
expressions also define other kinds of cardinalities. For example, the expression 
(0, Zc)V {ki, N) with k < ki is a new kind of cardinality that we call “at most k or 
at least kf\ It corresponds semantically to the set {n | 0 < n < k}U{n \ k\ < n}. 
Roughly speaking, CARD can be viewed as a data type specified by two operations 
A and V and freely generated by basic cardinality. Then |] defines a kind of 
algebra of that specification. 

3 Conceptual Schema 

Conceptual modeling of data obeys some rules called meta-rules. Meta-rules 
concern generic concepts and are independent of any applications. For instance, 
generic concepts of entity-relationship model concern entity, attribute, relation- 
ship, cardinality and label (role). Meta-rules for this model may include the 
following: 
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Rule 1 : Each entity type participating in a relationship type is accompanied 
with a (min, max) -cardinality and a role (optional). 

Rule 2 : Each attribute has a description which determines its type. 

Rule 3 : Some attributes of an entity type may be declared as key attributes. 
Rule 4 : Every relationship type is at least binary, and If an entity type par- 
ticipates in a relationship type twice, the corresponding roles must be different. 
Rule 5 : Every entity type has at least one attribute. 

Rule 6 : Every attribute name is either an entity type attribute name or a 
relationship type attribute name. 

Rule 7 : The same attribute name can not be used in an entity type and in 
a relationship type both (optional rule). 

Rule 8 : The same attribute name can not be used in two different entity 
types (optional rule). 

The core of a conceptual data modeling tool consists of an implementation 
of such rules. Any formalization of such rules can help designers of such systems. 
In what follows, we shall give a rigorous formalization of these rules in terms of 
simple mathematical concepts given in the previous section. 

Let ATT, ENT, REL, and LAB be enumerable pairwise disjoint sets which have 
no common element with CARD. Elements of these sets are identifiers representing 
names of concepts. We call an element of ATT, ENT, REL, and LAB an attribute 
name, an entity type name, a relationship type name and a label (or role), re- 
spectively. We also consider the set DESC = {mono, multi, composite} which 
is supposed to be disjoint from all other above sets. 

Definition 1 (Entity-Relationship schema) A conceptual ER-schema (or a 
ER-schema) is a tuple S = {dmtt, descmtt, emit, kmtt, r^ent, rmU) such that 

dmtt : ATT ^ DESC, 

desc-att : ATT — !■ ATT, where ATT = ATT U set ATT 

emit : ATT ENT, 

k.att : ATT ENT, 

r_att : ATT — ^ REL, and 

r.ent : REL x ENT x LAB — ^ CARD 

are partial functions satisfying the following conditions: 

2 d-att{A) G {mono, multi} desc_att(A) = A, 

d-att{A) = composite descjitt{A) G ATT and A ^ desc-att{A). 

3 k-att C emtt. 

4 (R,Ei,li) G de/(r_ent) 

(3^2, 3^2 {R,E 2 ,l 2 ) G de/(r_ent) A {{Ei yf E 2 ) V {h yf ^ 2 ))- 

5 de/(e_att) yf 0. 

6 e_att U r_att = de/(d_att). 

7 e_att D r_att = 0. ■ 

To see the connection between this definition, the above rules and the classical 
definition of the ER-diagram of an application, we show that a given application 
can be specified by giving a schema. Let A = de/(d_att), S = im(e_att). 
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TZ = proj_l((ie/(r_ent)), C = proj -3{def{T_ent)), and C = zm(r_att) be the 
sets of attribute names, entity types names, relationship types name, roles and 
(min, max) -cardinalities of the application, respectively. Then, the definition 
provides a model of the rules as follows: 

— d-att{A) = mono, multi or composite means that is a mono-valued, 
multi-valued, or a composite attribute; 

— desc_att describes a simple attribute by itself and a composite attribute by 
a set of attributes; 

— e-att{A) = E means that A is an attribute of entity type E, and k-att{A) = 
E means that A is a key attribute of E] 

— rjitt{A) = R means that A is an attribute of relationship type i?; 

— r-ent{R, E,l) = c means that entity type E participates in relationship type 
R with cardinality c and role r. 

Then, conditions 2-7 correspond to rules 2-7, and Rule 1 and 8 correspond to 
functionality of r_ent and e_ent, respectively. 

The above description can be expressed alternatively as follows. Let us define 
the following algebraic specification: 

Spec ER_Sch 

Sorts: ENTITY, RELSHIP, ATTR, ATTR, LABEL, CARDINALITY, DESCATT 

Ops: 

D_Att : ATTR — ^ DESCATT (partial), 

Desc_Att : ATTR — ^ ATTR (partial), 

E_Att : ATTR ^ ENTITY (partial), 

K_Att : ATTR ^ ENTITY (partial), 

R_Att : ATTR RELSHIP (partial) 

R Ent : RELSHIP ENTITY LABEL -Y CARDINALITY (partial) 

Axs: 

E,E> : ENT, R: RELSHIP, A: ATTR, 1,1’ : LABEL, c,c’ : CARDINALITY, D : DESCATT 
VA K_Att(A) = E E_Att(A) = E, 

VR 3 E, 3 E’, 3 c, 3 c’, 31, 3l’ 

(R_Ent(R, E, 1) = c) A (R_Ent(R, E’ , 1’) = c ’ ) A ( (EyfE ’ ) V(lyfl’)), 
ME 3A E_Att(A) = E, 

-.( 3A 3E 3E’ ((E_Att(A) = E)A(R_Att(A)=E’))) 

VA 3E ((E_Att(A) = E) V(R_Att(A) = E’)). 

Fact 1 (schema as algebra) Any ER-schema can be viewed as a “finite partial 
model” |] of the specification ER_Sch such that: 

|ATTR] = ATT, |RELSHIP] = REL 

[ENTITY] = ENT |DESCATT] = DESC 

[m^ = ATT U set ATT |LABEL| = LAB 
[CARDINALITY] = CARD 

[D_Att|(A) G {mono, multi} => desc_Att(A) = A 
[D_Att|(A) = composite desc_Att(A) G ATT and A ^ ATT. 

Conversely any finite partial model of ER_Sch satisfying the two last above con- 
ditions defines an ER-schema (in the above notation, for a sort s, |s] stands for 
classical notation []«, and for an operation /, [/] stands for /D). ■ 
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Note: Some authors j6] allow attribute names to be overloaded in an ER- 

diagram. This excludes optional rules 7 and 8. To do so in our formalism, we have 
to consider e_att, k-att and r_att as multi-valued functions (binary relations) 
and change Definition [I] and Fact [U mutatis-mutandis. To this end, for any 
multi-valued function / : X — >■ VfiY) and any P C X, we define def{f) = 
{x G X \ f{x) yf 0} and f{P) = U f{,x). We delete from Definition [f] the 

xeP 

constraint e-att fl r-att = 0. In this way our formalism stands for those multi- 
valued functions without any change. 

In the sequel we denote by A4odeZ(ER_Sch) the collection of models of ER_Sch 
determined by converse part of the above fact. 

4 Instances and Loose Semantics 

A base interpretation of an ER-schema S consists of associating a set |A] with 
each attribute name A G A. The set |A] is called the domain of A and often 
written as dom{A). Usually dom{A) is the set of concrete values of a type. This 
type is often a basic type like int, string, boolecin. But in most general case, 
it can also be a record type or a collection type (sets, bags, lists). More 
precisely, we consider the following type system: 

BASE : : = int I string I bool I ... 
coll : : = set I bag I list 
T : : = BASE I coll BASE 
Type : := T I {T, . . . , T}. 

Now, we interpret each attribute A by a type denoted |A] such that if d_att = 
mono then |A] G BASE, if d_att = multi then |A] G coll BASE, and if d_att = 
composite then |A] G {T, . . . ,T}. 

Every base interpretation of S can be extended in a “canonical” way in order 
to interpret entity and relationship types of S too. The extension is defined as 
follows: 

— Each entity type E with attributes {Ai, ■ ■ ■ , A„} is interpreted by the set 
|E] of all {Ai, • • • , A„}-tuples over |T>i] = dom{Ai) (1 < i < n). We view 
such a tuple as a function e : {Ai, • • • , A„} — t> IJ |Di] such that e{Ai), 

l<i<n 

denoted e.A^, is an element of |Di]. Each element e of |E] is called an entity 
of E and each e.Ai is an attribute value participating in e. 

— Each relationship type R with attributes {Ai,---,Afc} and entity types 
{El, • • • , En} is interpreted by the set |i?] of all |Ai, • • • , A^, Ei, • • • , E„}- 
tuples over |Ei] = dom{Ai) (0 < i < k) and \Ej\ {I < j < m). Thus 
|i?| is the set of functions r : |Ai, • • • , A^, Ei, • • • , E^} — >■ ( U [EJ) U 

l<i<k 

( U < i < k) is in |Ei] and r{Ej) (1 < j < to) 

l<j<m 

is in \Ej\. Each element r of |E] is called a relationship of R. Each r{Ai), 
denoted r.Ai, is an attribute value participating in r and each r(Ej), denoted 
r.Ej, is an entity participating in r. 
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Note: The above interpretations of [if] and |i?] take into account the fact that 
sets of attributes and entity types are unordered sets at the conceptual level. 
Traditionally those sets are implicitly regarded as ordered sets. In that case one 
can define {Ej as |Di] x • • • x |D„] , and |i?] as |L>i] x • • • x {Dkj x [ili] x • • • x . 
Then e.Ai corresponds to usual i-th component of the tuple e. 

Definition 2 (Instance) An instance I of schema S consists of: 

— a base interpretation | ], 

— for each E G £, a, finite subset [Eji of [if], and 

— for each R G TZ, a finite subset |i?]i of |i?J. ■ 

Definition 3 (Constraint satisfaction and loose semantics) Let I be an 

instance of an ER-schema and r-ent(R, E,l) = c. We say that I satisfies the 
cardinality constraint c for R and E, denoted R \=i (E,c), iff |e_R| G |c], where 
\eu\ is the number of elements r G |i?]i in which e participates. 

We say that an instance X for ER-schema satisfies the key constraints for entity 
type E K = k.att{E) satisfies: 

Ve G [A]x, Ve' G {Eji, (VA G K, e.A = e'.A) ^ e = e'. 

A valid instances of S is an instance satisfying all constraints of S. The collection 
of all valid instances of S is called the loose semantics of S. ■ 

The loose semantics of a schema S will be denoted Coose{S). It is clear that 
the empty instance is valid. A schema is called invalid if its loose semantics con- 
tains only the empty instance. Checking whenever an instance is valid is a hard 
problem in general setting. However, presence of some structural configurations 
may make this checking easier mm- 

5 The ER-Meta Model 

In this section we shall introduce a particular schema META_ER, called the meta- 
schema, in a way that each valid instance of the meta-schema is a schema, and 
vice-versa. In fact, the meta-schema is obtained by organizing, as a schema, the 
meta-concepts used in Definition [T] 

In a practical point of view implementing the meta schema corresponds to a 
a part of a design tool. We show that a SQL-like database language can serve as 
a host language for such an implementation. 

Meta schema 

We consider the following finite sets: 

metavl = {Djname, Desc_name, Ajname, Ejname, Rjname, Ljname, Card}, 
meta.f = { DESCATT, ENTITY, RELSHIP, ATTR, ATTR, LABEL}, 
meta_7?. = {D_Att , Desc_Att, E_Att, K_Att , R_Att , R_Ent}, 
meta_E = {blank}, 

meta_C = {(0, 1), (0, N) , (1, N) , (2, N)}. 
and we suppose that these sets are subsets of ATT, ENT, REL, LAB, and CARD, 

^ Some authors say satisfiable schema or consistent schema. 
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respectively 0 Then, we define the finite functions meta_e_att, meta_k_att, 
meta_r_att as follows: 



meta_e_att, meta_k_att, meta_r_att: ATT — >■ ENT 
meta_e_att (A) = meta_k_att (A) = 

{Djiame DESCATT, Descjiame i—> ATTR, A_name ATTR, Ejiame 
R_name RELSHIP, L_name i— >■ LABEL, Card undefined} 

RJEnt if A = Card, 
undefined otherwise 



ENT, 



meta_r_att(A) = 



The definition domain of meta_e_att and meta_k_att, and meta_r_att are finite 
sets meta^ and meta_£l, respectively. We suppose that all meta attribute are 
simple and mono- valued. This define two functions: 

meta_d_att : ATT — ^ DESC and meta_desc_att : ATT — >■ ATT, 
with finite definition domains meta_^. 

Now, we define the function meta_r_ent: REL x ENT x LAB CARD by the 
following table: 



meta_r_ent 


REL 


ENT 


LAB 


CARD 




E_Att 


ATTR 


blank 


(0, 1) 




E_Att 


ENT 


blank 


(1, N) 




K_Att 


ATTR 


blank 


(0. 1) 




K_Att 


ENT 


blank 


(0, N) 




R_Att 


ATTR 


blank 


(0. 1) 




R_Att 


RELSHIP blank 


(0, N) 




R_Ent 


RELSHIP blank 


(2, N) 




R_Ent 


LABEL 


blank 


(1, N) 




R_Ent 


ENT 


blank 


(0, N) 




Desc_att ATTR 


blank 


(1. 1) 




Desc_att ATTR 


blank 


(0, N) 



Fact 2 META_ER = (meta_d_att, meta_desc_att , meta_k_att, meta_r_ent, 
meta_r_att) is an ER-schema that we call the meta-schema of ER-model. ■ 



Meta instances 

In order to define a meta instance we extend our types as follows: 

I DENT = ATT I ENT I REL I LAB I CARD 
ATT : ; = ATT I set ATT 
Meta_type ::= IDENT I ATT 
Type* : : = Type I Meta_type . 

Now we define a base interpretation of META_ER as follows: 



^ Our definition of schema uses a role for every entity type. In fact, however, roles are 
only needed when two entity types participate in the same relationship type. We 
consider blank as a non printable element of LAB meaning an unnecessary role. 
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|A_namie] = ATT |E_name] = ENT 
|R_namie] =REL |L_namejj =LAB 
|D_namie] =DESC |Desc_namie] =ATT 
|Card] =CARD 

The extension of that base interpretation to meta-entities and meta-relationships 
is defined by 



IDESCATT] 

[ENTITY] 

[ATTR] 

[ATTRJ 

[LABEL] 



= DESC = [D_Att| 

= ENT = [E-Att] = [K_Att| 

= ATT = |R_Att] 

= ATT = |Desc_Att| 

= LAB [RELSHIP] = REL 

[R_Ent| = |REL| X |ENT| X [LAB] X [CARD] 



Fact 3 Every schema S defines a valid instance Is of META_ER on the above 
base interpretation. ■ 



In fact META_ER as defined above is a special finite algebra of the specification 
ER_Sch. 

Corollary 1 There is a valid instance A4 of META_ER that defines the schema 
META_ER itself. 

Indeed, META_ER is an ER-schema. Hence, it defines a valid instance Ai of META_ER. 
This instance is defined by [ATTRj^vi := meta_yl, [ENTITYJ^vi := meta.if, 
[E_Att|7K def (meta_d_att), and so on. Clearly A4 satisfies all constraints 
of META_ER. We summarize the above corollary by saying : 

The meta schema is a valid instance of itself. 



Fact 4 Each valid instance S of META_ER defines a ER-schema Sx- ■ 



Following Fact[Tl each schema can be viewed as a finite model of ER_Sch. Recall 
that AIod(ER_Sch) is the class of all finite models of ER_Sch satisfying two 
conditions of fact |T] and £oose (META_ER) is the loose semantics of META_ER (see 
definition [3|) . 

Theorem 1 £oose (META_ER) is isomorphic to A4od(ER_Sch) . 

Indeed, for any valid instance I of META_ER define 'f'(T) = Sx, and for any element 
S of A4od(ER_Sch) define <P{S) — Is- Then it can be proved that and T are 
inverse of each other. In particular, (MET A _ER)) = META_ER. ■ 

Implementing the meta schema within SQL 

Now, we shall show how we can use the database language SQL as a host language 
for implementing a part of a conceptual design tool for database applications. 
Roughly speaking. 
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we transform the meta schema META_ER into a relational database 
schema RelMETA_ER in such a way that every instance of META_ER corre- 
sponds to an instance of RelMETA_ER and vice-versa. We implement then 
RelMETA_ER within SQL adding PRIMARY KEY, FOREIGN KEY, NOT NULL, 
and global constraints. An instance S of META_ER can be defined as a set 
of INSERT commands for ReIMETA_ER. This set of commands forms an 
instance Is of ReIMETA_ER. The success of these commands tells us that 
the instance I is a a valid instance of META_ER. 



We consider a SQL implementation with CHECK OPTION. In such a SQL the 
relational database schema ReIMETA_ER is defined as follows: 

CREATE TABLE D_Att(Ajname CHAR(IO) , D_name CHAR(IO) NOT NULL, 

PRIMARY KEY (A_name)); 

CREATE TABLE desc_Att (A jiame CHAR(IO) , Desc_name CHAR(IO) NOT NULL, 
FOREIGN KEY (Ajiame) REFERENCES Djname ON DELETE CASCADE); 

CREATE TABLE E_Att (Ajiame CHAR(IO) , E_name CHAR(IO) NOT NULL, 

PRIMARY KEY (A_name) , 

FOREIGN KEY (Ajiame) REFERENCES Djname ON DELETE CASCADE) ; 

CREATE TABLE K_Att(A_name CHAR(IO) , E_name CHAR(IO) NOT NULL 
PRIMARY KEY (A_name) , 

FOREIGN KEY (Ajiame) REFERENCES E_Att ON DELETE CASCADE) ; 

CREATE TABLE R_Ent(R_name CHAR ( 10) , Ejiame CHAR ( 10) , 

Ljiame CHAR(IO) NOT NULL, Card CHAR(IO) NOT NULL, 

PRIMARY KEY (Rjiame, E_name, Ljname) , 

CONSTRAINT unknown_E_name CHECK 

(Ejiame IN (SELECT E_name FROM E_Att))); 

CREATE TABLE R_Att(Ajname CHAR(IO) , Rename CHAR(IO) , 

PRIMARY KEY (A_name) , 

FOREIGN KEY (Ajiame) REFERENCES Djname ON DELETE CASCADE, 

CONSTRAINT unknown_R_name 

CHECK (Rjiame IN (SELECT R_name FROM R_Ent))); 

CREATE ASSERTION Cl CHECK 

( NOT EXISTS (SELECT Rjiame, COUNT (Ejiame) FROM R_Ent 
GROUP BY Rjiame HAVING COUNT (Ejiame) <2)); 

CREATE ASSERTION C2 CHECK 

(NOT EXISTS (SELECT Ajname FROM Djiame 
WHERE Ajiame NOT IN 
(( SELECT A_name FROM E_Att) 

UNION ( SELECT Ajiame FROM R_Att)))); 

CREATE ASSERTION C3 CHECK 

( NOT EXISTS (SELECT A_name FROM E_Att 

WHERE A_name IN ( SELECT Ajiame FROM R_Att)) 

AND NOT EXISTS (SELECT Ajiame FROM R_Att 
WHERE A_name IN (SELECT Ajiame FROM E_Att))); 
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Theorem 2 Each valid ER-schema S defines a valid relational database instance 
ip{S) over the relational schema RelMETA_ER. Conversely, each valid instance I 
o/RelMETA_ER defines a valid ER-schema Moreover, if and (f are inverse 

of each other; that is ip{4>{I)) = I and 4>{il){S)) =50 

Proof: In what follows the set of answers of a query g on a database / over 
the schema RelMETA_ER is denoted |g]/. 

Let 5 be a schema. According to the Fact 0 5 can be seen as an instance 1$ 
of META_ER. To define 4>{S) we insert within a unique transaction all elements 
of |D_Att]i 5 , |Desc_Att]i 5 , lEAttJi^, |K_Att]xs, |R_Ent]xs and |R_Att]xs 
in the relations D_Att, Desc_Att, E_Att, R_Ent and R_Att of RelMETA_ER , 
respectively. Conversely, let / be a valid instance of RelMETA_ER (i.e. an instance 
satisfying all constraints and all general ASSERTIONS). We define the schema 
if {I) = {d-att,desc-att,k-att,r-ent,r-att) as follows: 



d. Att= ISELECT * FROM D_Att;]/ desc.att = |SELECT * FROM Desc_Att;]/ 

e. att= ISELECT * FROM E_Att;]/ k.att = |SELECT * FROM K_Att;]/ 

r_ent = |SELECT * FROM R_Ent;]/ r.att = |SELECT * FROM R_Att;]/ 

It is clear that (f and if are inverse of each other. Moreover, conditions of the 
definition [T] are respectively equivalent to the success on insert commands. 

Therefore if 5 satisfies conditions of the definition [T] then (f{S) is a valid 
instance of RelMETA_ER. Conversely, if I is a valid instance of META_ER then if (I) 

satisfies conditions of the definition [U This completes the proof. ■ 



Nota: Checking assertions Cl to C3 is equivalent, respectively, to checking that 
the following queries Qi to Qs have no answers: 



Q2 ■ 

SELECT A_name 



Qi: 

SELECT R_name, COUNT (E_name) 

FROM R En t 
GROUP BY R_name 
HAVING COUNT (E_name) <2; 

Qa'- 

(SELECT SELECT Auiame FROM E_Att) 
INTERSECT (SELECT SELECT A_name FROM 



FROM Djname 
WHERE Ajiame NOT IN 
((SELECT Auiame FROM E_Att) 
UNION 

(SELECT Ajiame FROM R_Att)); 



R_Att) ; 



As a result one can replace the assertions by checking emptiness of these 
queries. This is a good solution when the the current SQL implementation does 
not support global assertion constraints. For more details on this implementation 
see |3] 



6 Related Works, Conclusion, and Further Research 

Formalization and unification of conceptual modeling approaches have been of 
interest for many authors. Several works extend the original Chen proposal |3] 

■* By a valid instance of a relational database we mean an instance that satisfies all its 
constraints. 
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to new concepts, including inheritance and objects |7l6j . For instance, in m a 
formal higher order ER-model has been proposed. In this model the notion of 
relationship has been extended by introducing a relationship of higher order, 
permitting to nest relationships. To capture more semantics, a wide variety of 
constraints have been introduced in [I9l2ll2j . In |8H2j a formal approach has 
been proposed for unification of these constraints. An amount of papers are de- 
voted to the delicate problem of checking validity of an ER-schema in presence 
of constraints mB- However, in all these works constraints are specified se- 
mantically. Meta modeling is another subject which has been used in various 
approaches of conceptual modeling, including reverse engineering, schema inte- 
gration and model transformation. For instance, in [T] a meta model is used for 
reverse engineering, more precisely for discovering inheritance hidden links in a 
relational schema. From our point of view, the border between conceptual and 
physical levels is blurred in the above proposals, and their meta models are ad 
hoc and lack a formal basis. In this paper we have proposed a formal approach 
for ER-models. The approach does a neat separation between the specification 
of conceptual and physical data of an application. Another particularity of the 
present work is an attempt to distinguish between specification of constraints 
and their satisfaction. We have proved that our formalism is self-contained in 
the sense that all schemas are instances of a special schema: the meta schema. 
Proofs of main results are omitted for space limitation. 

Many interesting aspects of conceptual modeling are not developed in this ex- 
tended abstract, dynamic aspects and data warehousing m are among them. 
It is interesting to give a formal specification of the underlying dynamic system. 
The technique presented in this paper seems to be applicable for more sophis- 
ticated modeling approaches, especially for object modeling and a semantics of 
UML. We are currently investigating these research directions. 
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Abstract. Data integration aims to provide a uniform integrated access 
to multiple heterogeneous information sources, designed independently 
and having strictly related contents. The heterogeneity among sources 
may range from the hardware and software platforms to the data model 
and the schema used to represent information. 

In this paper we consider data inconsistencies and deal with the inte- 
gration of possibly conflicting instances coming from different sources 
and related to the same concept. In order to support the data integra- 
tion process, we introduce some integration operators for combining data 
coming by different sources, preserving the information provided by each 
source separately. Generally, a view obtained by integrating heteroge- 
neous sources could contain instances which are inconsistent, w.r.t. some 
integrity constraints defined on the integrated view schema. Therefore, 
we present a technique which allows us to compute consistent answers 
to queries involving possibly inconsistent data. 



1 Introduction 

A central topic in database science is the construction of integration systems, 
designed for retrieving and querying uniformly data stored in multiple informa- 
tion sources. The main problem which integration systems have to deal with is 
the heterogeneity of their sources, often designed independently for autonomous 
applications. The problem of integrating heterogeneous sources has been deeply 
investigated in the fields of multidatabase systems federated databases m 
and, more recently, mediated systems [ 20122 ]. Mediator-based architectures are 
characterized by the presence of two types of components: wrappers, which trans- 
late the local languages, models and concepts of the data sources into the global 
ones, and mediators, which take in input information from one or more compo- 
nents below them and provide an integrated view of them [zno]. Views, managed 
by mediators, may be virtual or materialized. When a mediator receives a query, 
it dispatches subqueries to the components below it (wrappers and/or medi- 
ators), collects the results and merges them in order to construct the global 
answer. Mediators have to cope with schema and value inconsistencies that may 
be present in the information coming from the different sources. The first kind 
of inconsistency arises when different sources use different schemas to model the 



D. Bj0rner, M. Broy, and A. Zamulin (Eds.): PSI 2001, LNCS 2244, pp. 349-|36^ 2001. 
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same concept, while the second one arises when different sources record different 
values for the same object EEH. 

In this paper, we focus our attention on the integration of conflicting instances 
um related to the same concept and possibly coming from different sources. 
We introduce an operator, called Merge operator, which allows us to combine 
data coming from different sources, preserving the information contained in each 
of them and a variant of merge operator, i.e. the Prioritized Merge operator, 
which can be employed to combine data using preference criteria Generally, at 
any level of the architecture, the integrated information may be inconsistent, 
i.e. it doesn’t satisfy some integrity constraints associated with the schema of 
the mediator. Thus we present a technique, based on the identification of tuples 
satisfying integrity constraints and on the selection of tuples satisfying the query, 
which permits us to compute consistent answers, i.e. maximal sets of atoms which 
do not violate the constraints. 



1.1 Background 

A (disjunctive Datalog) rule r is a clause of the form 

Ai V • • • V Afc ^ Bi, ■■ ■ , Bm, not Bm+i , • • • , not k + m + n > 0, 

where Ai, ■ ■ ■ , Ak, Bi, ■ ■ ■ , Bn are atoms of the form p{ti , ..., th), p is a predicate 
of arity h and the terms t\, ..., th are constants or variables. In the following, we 
also assume the existence of null value (_L) in the domain of the constants in 
order to model a lack of knowledge. The disjunction Ai V • • • V is the head of 
r, while the conjunction Bi, - ■ ■ , Bm, not Bm+i , ■ ■ ■ , not Bn is the body of r. We 
also assume the existence of the binary built-in predicate symbols (comparison 
operators) which can only be used in the body of rules. 

An interpretation M for V is any subset of the Herbrand base of B-p', M is a 
model of V if it satisfies all rules in ground{'P). The (model-theoretic) seman- 
tics for positive V assigns to V the set of its minimal models MM(P), where a 
model M for V is minimal, if no proper subset of M is a model for V |TH]. The 
more general disjunctive stable model semantics also applies to programs with 
(unstratified) negation [S]. Disjunctive stable model semantics generalizes stable 
model semantics, previously defined for normal programs jH]. For any interpreta- 
tion I, denote with the ground positive program derived from groundijP) by 
1) removing all rules that contain a negative literal not a in the body and a G I, 
and 2) removing all negative literals from the remaining rules. An interpretation 
M is a (disjunctive) stable model of V if and only if M G MM(P^). For general 
V, the stable model semantics assigns to V the set SM{'P) of its stable models. 
It is well known that stable models are minimal models (i.e. SM(P) C MM(P)) 
and that for negation free programs minimal and stable model semantics coin- 
cide (i.e. SM(P) = MM(P)). Observe that stable models are minimal models 
which are ‘supported’, i.e. their atoms can be derived from the program. 
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1.2 Extended Disjunctive Databases 

Extended Datalog programs extend standard Datalog programs with a different 
form of negation, known as classical or strong negation, which can also appear in 
the head of rules. Thus, while standard programs provide negative information 
implicitly, extended programs provide negative information explicitly and we can 
distinguish queries which fail in the sense that they do not succeed and queries 
which fail in the stronger sense that negation succeeds [IhllOll,')) . An extended 
atom is either an atom, say A or its negation -■ A. An extended Datalog program 
is a set of rules of the form 

Aq V ... V 4 E'l, ..., Bjyi, not not Bj, 

where fc + n > 0, Aq, A^, Bi, B„ are extended atoms. A (2-valued) inter- 
pretation I for an extended program P is a pair {T, F) where T and F define a 
partition of B-pU-'B-p and -'Bp = {-iA| A G Bp}. The truth value of an extended 
atom L G BpU-'Bp w.r.t. an interpretation / is equal to (i) true \i L G T and, (ii) 
false ii A G F. Moreover, we say that an interpretation I = (T,F) is consistent 
if there is no atom A such that A G T and -■A G T. The semantics of an extended 
program V is defined by considering each negated predicate symbol, say -<p, as a 
new symbol syntactically different from p and by adding to the program, for each 
predicate symbol p with arity n the constraint ^ p{Xi, A„), -ip(Ai, ..., A„). 
The existence of a (2- valued) model for an extended program is not guaranteed, 
also in the case of negation (as-failure) free programs. For instance, the program 
consisting of the two facts a and -la does not admit any (2-valued) model. In 
the following, for the sake of simplicity, we shall also use rules whose bodies 
may contain disjunctions. Such rules, called generalized disjunctive rules, are 
used as shorthands for multiple standard disjunctive rules. More specifically, a 
generalized disjunctive rule of the form 

Ai V ... V Afc ^ (Si,i V ... V ..., (B„.i V ... V Bn^mJ 

denotes the set of standard rules 

Ai V ... V Afc G- i?i,q , ..., Bn^ifi j, i 

where 1 < j < n and 1 < ij < ruj. Given a generalized disjunctive program V, 
st(V) denotes the standard disjunctive programs derived from V by rewriting 
body disjunctions. 



1.3 Queries 

Predicate symbols are partitioned into two distinct sets: base predicates (also 
called EDB predicates) and derived predicates (also called IDB predicates). Base 
predicates correspond to database relations defined over a given domain and they 
do not appear in the head of any rule whereas derived predicates are defined by 
means of rules. Given a database D, a predicate symbol r and a program V, 
D{r) denotes the set of r-tuples in D whereas Vd denotes the program derived 
from the union of V with the tuples in D, i.e. Vd = V U {r(t) G- \ t G D{r)}. 
In the following a tuple t of a relation r will be also denoted as a fact r{t). 
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The semantics of Vd is given by the set of its stable models by considering 
either their union (possible semantics or brave reasoning) or their intersection 
{certain semantics or cautious reasoning) . A (relational) query over a database 
defines a function from the database to a relation. It can be expressed by means 
of alternative equivalent languages such as relational algebra, ‘safe’ relational 
calculus or ‘safe’ non-recursive Datalog [T^. In the following we shall use Datalog. 
Thus, a query is a pair {g, V) where P is a safe non-recursive Datalog program 
and g is a predicate symbol specifying the output (derived) relation. Observe 
that relational queries define a restricted case of disjunctive queries. The reason 
for considering relational and disjunctive queries is that relational queries over 
databases with constraints can be rewritten into extended disjunctive queries 
over databases without constraints. 



2 Data Integration 

A mediator provides an integrated view over a set of information sources. Each 
of these sources may be a source database or a database view (virtual or mate- 
rialized) furnished by another mediator. At each level of the integration system, 
the information provided by different sources and related to the same concept 
is combined. The necessity of completing data stored at a source is due to the 
fact that some information may not be available at that source because it is not 
modeled within the schema of the source or simply because some instances con- 
tain undefined values for some attributes. The way we integrate different sources 
preserves the information contained in each of them, since we try to complete the 
information but we never modify that already available. In fact our integration 
operators, described in the following paragraphs, are designed for reducing the 
incompleteness and redundancy of information but they do not solve all data 
conflicts, as such operation could lead to loss of information. 

Let us introduce some basic definitions in order to simplify the description of 
our approach. 

We assume that a mediator has its own schema, that we call mediator schema, 
and a set of integrity constraints whose satisfaction means that data are consis- 
tent. The mediator schema represents, in an integrated way, some relevant con- 
cepts that may be modeled differently within the schemas of different sources. 
Integrity constraints are first order formulas which must always be true. Al- 
though in this paper we only consider functional dependencies, our approach to 
manage inconsistent data is more general. 

Let us adopt the relational model for referring schemas and instances pertain- 
ing to the mediator and the sources it integrates. 

Notation: Let i? be a relation name, then we denote by: 

— attr(R) the set of attributes of R; 

— key(R) the set of attributes in the primary key of R; 

— inst(R) an instance of R (set of tuples). 
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Moreover, given a tuple t G inst{R), key{t) denotes the values of the key at- 
tributes of t. In the rest of the paper we will use the name of a relation for 
denoting its content, unless that generates ambiguity. 

We assume that relations associated with the same concept have been homog- 
enized m with respect to a common ontology, so that attributes denoting the 
same concepts have the same name and the same domain. We say that two ho- 
mogenized relations R and S, associated with the same concept, are overlapping 
if key{R) = key{S). 

Definition 1. Let Ri, R^ be a set of overlapping relations. A relation i? is a 
super-relation of i?i, ..., i?„ if the following conditions hold: 

- attr{R) = attr{Ri), 

— key{R) = key{Ri) V i = l..n. □ 

Moreover, if i? is a super-relation of i?i, ...,Rn, then we say that Ri is a sub- 
relation of R for i = l..n. 

A mediator defines the content of any global relation as an integrated view of 
the information provided by all its sub-relations. Once the logical conflicts due 
to the schema heterogeneity have been resolved, conflicts may arise, during the 
integration process, among instances provided by different sources. In particular, 
the same real-world object may correspond to many tuples (possibly residing in 
different overlapping relations), that may have the same value for the key at- 
tributes but different values for some non- key attribute. In our approach both 
source relations and integrated views could have inconsistent instances. In par- 
ticular, it is possible that a relation contains more than one tuple with the same 
value for the key attributes. A set of tuples with the same key value is called 
c-tuple (cluster of tuples) [T], so in this context we often consider relations as 
sets of c-tuples. 

The content of an integrated view may be looked at as the result of an inte- 
gration operator applied to the overlapping relations which constitute the infor- 
mation sources for that view. For the sake of simplicity, in the rest of the paper 
we consider binary operators for integrating source relations. 

Definition 2 . Let R\ and i?2 be two overlapping relations, then an integration 
operator 0 is a binary operator which produces an integrated relation 
such that i?i0i?2 is a super-relation of R\ and i?2 and its tuples are obtained by 
combining the values contained in Ri and i?2- 

In order to provide a simple framework for characterizing and evaluating the 
various integration operators, we introduce a binary relationship for comparing 
two tuples or two relations. 

Definition 3. Let DS be a set of attributes and t\,t2 be two tuples over DS, 
then ti C t2 if for each attribute A in DS, ti\A\ = t2[A\ or ti\A\ = null. 
Moreover, given two relations R and S over DS, i? C S' if Vti S inst{R) 3 t 2 G 
inst{S) s.t. ti C t2- □ 

On the basis of Definition 0 , we define in the following some intuitive properties 
for an integration operator. 
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Definition 4. Let R\ and i?2 be two overlapping relations and 9 be an integra- 
tion operator, then 9 is: 

— ^-Complete if Ri C R\9R2 and i?2 E R\9R2 

— \Z-Correct if Vt G inst{Ri9R2) s.t. {t' G R\ or t' G R2) and t' Qt □ 

Informally, if an integration operator is both C-Complete and C-Correct it 
preserves the information provided by the sources. In fact it could modify some 
input tuples by replacing null values with not null ones, but all the associations 
of not null values which were contained in the source relations will be inserted 
into the result. An important feature of the integration process is related to the 
way conflicting tuples provided by overlapping relations are combined. Simple 
examples of integration operators are the union and the natural join. It can be 
immediately verified that the former is both C-Correct and E-Complete, whereas 
the latter is C-Correct but not E-Complete. However, the relation obtained by 
means of the union operator could be quite redundant, since tuples relative to the 
same real-world instance are not joined at all. A better example of integration 
operator is constituted by the outer join operator (natural), which is C-Correct 
and E-Complete, and produces a relation less redundant than the union. In fact 
some tuples in the outer join relation could be obtained by merging sets of tuples 
contained in the union relation, i.e. i?i U i?2 E Ri ZlxC i?2. 

In the following section we define two integration operators, namely the Merge 
Operator and the Prioritized Merge Operator. The former tries to reduce the 
information redundancy inside the integrated view but preserves the information 
provided by both the source relations. On the contrary, the prioritized operator 
eliminates some inconsistency, since in case of conflicting values it prefers the 
information contained in the first input relation. 



The Merge Operator 

Let us first introduce the binary operator <P which replaces null values occurring 
in a relation with values taken from a second one. In more detail, given two 
relations R and S such that attr{S) C attr{R), the operator is defined as follows: 

‘P{R, S) — { t € R \ flti G S s.t. key{t) = key(ti) } U 

{, 1 . n.3„ . s ^ 

Given two overlapping relations S'! and S'2, the merge operator, denoted by 
Kl, integrates the information provided by Si and S'2. Let S = Si Kl S2, then 
the schema of S contains both the attributes in Si and S2, and its instance is 
obtained by completing the information coming from each input relation with 
that coming from the other one. 

Definition 5. Let Si and S2 be two overlapping relations. The merge operator 
is a binary operator defined as follows: 



Si K S2 = 4 >(Si □>< S2, S2) U 4 >(Si MZ S2, Si) 



□ 
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Si Kl S 2 computes the full outer join and extends tuples coming from S\ (resp. 
S 2 ) with the values of tuples of S 2 (resp. ^i) having the same key. The extension 
of a tuple is carried out by the operator which replaces null values appearing 
in a given tuple of the first relation with values appearing in some correlated 
tuple of the second relation. Thus, the merge operator applied to two relation 
Si and S 2 ‘extends’ the content of tuples in both Si and S'2. 

Proposition 1 . The merge operator is an integration operator, w.r.t. Definition 
\E In fact, let Si and S2 be two overlapping relations, then 

— attr{SiM S2)= attr{Si)[Jattr{S2) 

- key{Si Kl S2) = key{Si) = key{S2), □ 



Example 1 . Consider the relations S'! and S 2 reported in Fig. [T]in which K is 
the key of the relations and the functional dependency Title — >■ Author holds. 
The relation T is obtained by merging and S2, i.e. T = SiM S'2. 
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Fig. 1. 



Let Si and S 2 be two overlapping relations, let K = key{Si) = key{S 2 ), 
A = {ai, ..., a„} = attr{Si)r\attr{S 2 ) — K , B = {61, ..., 6^} = attr{Si) — attr{S 2 ) 
and C = {ci,...,Cg} = attr{S 2 ) — attr{Si). The merge operator introduced in 
Definition |5] can easily be expressed by means of the following SQL statement 
(where, given a relation R and a set of attributes X = Xi, ■..,Xt, the notation 
R.X stands for R.Xi, R.Xt): 

SELECT Si.K, Si.B, COALESCE(S'i.oi, S'2-ai), .., COALESCE(S'i.a„, S'2.a„), £'2.6' 

FROM £1 LEFT OUTER JOIN £2 ON Si-K = S2-K 

UNION 

SELECT S 2 .K, Si-B, C0ALESCE(£2.ai, £i.ai), .., C0ALESCE(£2.a„, £i.a„), £2.C 
FROM £1 RIGHT OUTER JOIN £2 ON Si.K = S2-K 

where the standard operator COALESCE(ai, ..., a„) returns the first not null value 
in the sequence. 
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Proposition 2. 



- SiMS2 = S 2 M Si 

— if inst{Si) does not contain null values then 

Sim Si = Si 

- Si n Si mS2 and S'2 E K S2 

— Vis inst{Ri El R 2 ) 3t' s.t. 

(f G Ri or t' G R 2 ) and t' Qt 



( commutativity ), 

(idempotency), 

(Q-Completeness), 

(\Z-Correctness). □ 



Obviously, given a set of overlapping relations S\, S 2 , ■■■, Sn, the associated super- 
relation S can be obtained as S = E 5'2 El ... El S'„. In other words S is the 
integrated view of Si, S 2 , ■■■, Sn- 



The problem we are considering is similar to the one treated in 1211 . which 
assumes the source relations involved in the integration process have previously 
been homogenized. In particular, any homogenized source relation is a fragment 
of the global relation, that is it contains a subset of the attributes of the global 
relation and has the same key K. The technique proposed in m makes use 
of an operator bd, called Match Join, to manufacture tuples in global relations 
using fragments. This operator consists of the outer-join of the ValSet of each 
attribute, where the ValSet of an attribute A is the union of the projections of 
each fragment on {K, A}. Therefore, the application of the Match Join operator 
produces tuples containing associations of values that may not be present in any 
fragment. 

Example 2. We report below the relation obtained by applying the Match Join 
operator to the relations Si and S 2 of Example [T] 
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□ 

The Match Join operator is E-Complete, but it is not E-Correct, since it mix 
values coming from different tuples with the same key in all possible ways. As a 
consequence, when applying the Match Join operator to the source relations of 
Example 1 we obtain an integrated view T violating the functional dependency 
Title — >■ Author. On the contrary, the merge operator here introduced only tries 
to derive unknown values and for each cluster of tuples in the derived relation the 
functional dependencies are satisfied. Observe also that the Match Join operator 
may not satisfy the idempotent property, i.e. Si Si Si, even if the source 
relation does not contain null values. 
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In Table [T] some integration operators are compared, by taking into account 
the following relevant properties: C-Completeness, C-Correctness, and key con- 
sistency preservation. The last property indicates that whenever the input re- 
lations are consistent w.r.t. the key functional dependency, i.e. all c-tuples are 
singleton, also the integrated relation will be consistent w.r.t. the key func- 
tional dependency. We can observe that only the union, the outer join (natural) 
and the merge operator preserve the source information, i.e. they are both C- 
Correct and C-Complete. However, the relation produced by the last operator 
contains a lower number of unknown values. In fact Ri U R2 Q Ri ^ R2 and 
Ri ZMZ R2QR1M R2. 

Table 1. Properties of various integration operators 



operator 


\Z-Complete 


\Z-Correet 


Preserves 

Key-Consistency 


union 


yes 


yes 


no 


naturaljoin 


no 


yes 


yes 


outer join 


yes 


yes 


no 


match] oin 


yes 


no 


no 


merge 


yes 


yes 


no 



3 Answering Qneries Satisfying User Preferences 

In this section we introduce a variant of the merge operator, which allows the 
mediator to answer queries according to the user preferences. Preference criteria 
are expressed by a set of constraints called preference constraints which permit 
us to define a partial order on the source relations. 

A preference constraint is a rule of the form Si <C Sj, where Si,Sj are two 
source relations. Preference constraints imply a partial order on the source re- 
lations. We shall write Si S2 St StS a. shorthand of {Si S2, S2 

S3, ...,Sk-i <C Sk}- The presence of such constraints requires the satisfaction of 
preference criteria during the computation of the answer. A priority statement 
of the form Si <C Sj specifies a preference on the tuples provided by the relation 
Si with respect to the ones provided by the relation Sj. 



The Prioritized Merge Operator 

In order to satisfy preference constraints, we introduce an asymmetric merge 
operator, called prioritized merge operator, which gives preference to data coming 
from the left relation, when conflicting tuples are detected. 

Definition 6. Let Si and S2 be two overlapping relations and S'2 = S2IX 
{'^key{S 2)^2 ~ '^key{Si)^i) the Set of tuples in S2 not joining with any tuple in Si. 
The prioritized merge operator is defined as follows: 

Si<S2= HSi S2, S2) U {Si cxzS^) 



□ 



358 S. Greco, L. Pontieri, and E. Zumpano 



The prioritized merge operator includes all tuples of the left relation and only 
the tuples of the right relation whose key does not identify any tuple in the left 
relation. Moreover, only tuples ‘coming’ from the left relation are extended since 
tuples coming from the right relation, joining some tuples coming from the left 
relation, are not included. Thus, when integrating relations conflicting on the 
key attributes, the prioritized merge operator gives preference to the tuples of 
the left side relation and completes them with values taken from the right side 
relation. 

Example 3. Consider the source relations S\ and S 2 of Example [TJ The relation 
T = Si<iS 2 is: ^ 
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The merged relation obtained in this case differs from the one of Example [T] 
because it does not contain the tuple {3, Flowers, Smith, 1965) coming from 
relation S' 2 . □ 



Proposition 3. Let Si and S 2 be two relations, then: 

- Si<S 2Q SiM S 2 , 

- SiMS 2 = {Si<S2)U{S2<Si), 

- V t G <i?2) s.t. (t' G i?i or t' G R 2 ) and t' Qt (Q-Correctness) , 

- SicSi = Si. □ 



Obviously, the prioritized merge operator is not G-Complete because some in- 
formation contained in the right input relation might be lost. In fact, when there 
are tuples belonging to different input relations and having the same key values 
but different values for some other attributes, for these attributes the operator 
holds only the values coming from the left relation. 

The prioritized merge operation Si<S 2 , introduced in Definition!^ can easily be 
expressed by means of an SQL statement, as follows: 

SELECT Si.K, Si.B, COALESCE(S'i.ai, S'2-ai), .., COALESCE(S'i.a„, S 2 .a„),S 2 .C 

FROM Si LEFT OUTER JOIN S '2 ON Si-K = S 2 .iL 

UNION 

SELECT S2.K,mLL{B), S2.A, S2-C 
FROM S2,Si 

WHERE S 2 .iL NOT IN (SELECT Si.iL FROM Si) 

where the function NULL(i?) assigns null values to the attributes in B. 
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4 Managing Inconsistent Data 

We assume that each mediator component involved in the integration process 
contains an explicit representation of intentional knowledge, expressed by means 
of integrity constraints. Integrity constraints, usually defined by first order for- 
mulas or by means of special notations, express semantic information about 
data, i.e. relationships that must hold among data. Generally, a database D has 
a set of integrity constraints IC associated with it. D is said to be consistent if 
D ^ XC, otherwise it is inconsistent. In this paper we concentrate on functional 
dependencies. We present a technique, introduced in |13| . which permits us to 
compute consistent answers for possibly inconsistent databases. The technique 
is based on the generation of a disjunctive program T>V(XC) derived from the 
set of integrity constraints IC. 



4.1 Repairing and Querying Inconsistent Databases 

Repaired databases are consistent databases which are derived from the source 
database by means of a minimal set of insertion and deletion of tuples. Given 
a (possibly inconsistent) database D, a repair for D is a pair of sets of atoms 
such that (i) R^r\R~ = 0, (ii) DUR'^ — R~ \= IC and (Hi) there is no 
pair ,S~) ^ (i?+, R“) such that C i?+, S~ C R~ and DiJS^ — S~ \= IC. 
The database D U — R~ will be called the repaired database. 

Thus, given a repair R, denotes the set of tuples which will be added to the 
database, whereas R~ denotes the set of tuples of D which will be deleted. In 
the following, for a given repair R and a database D, R{D) — DU — R~ 
denotes the application of i? to Zl. 

It is possible to compute repairs for an inconsistent database by evaluating 
the extended Datalog program T>V(IC), obtained by rewriting the integrity con- 
straints IC into disjunctive rules, over the extensional database. In the rest of 
this section we focus our attention on functional dependencies, i.e. a particular 
class of integrity constraints. 

Definition 7. Let c be a functional dependency x ^ y over P, which can be 
expressed by a formula of the form (Vx, y,z,u,v)[ P{x, y, u) A P{x, z,v) D y = z] 
then, dj(c) denotes the extended disjunctive rule 

-•P(x, y, u) V ~^P{x, z, v) ^ P{x, y, u), P{x, z,v),y^ z 

Let IC be a set of functional dependencies, then VV{IC) = { dj{c) | c G IC }. □ 

Thus, VV{IC) denotes the set of disjunctive rules obtained by rewriting IC. 
SM.{V'P{IC),D) denotes the set of stable models of W(IC) U D. 

Given a database D and a set of functional dependencies IC defined on its 
schema, every stable model in SM{VV{IC),D) can be used to define a possible 
repair for the database by interpreting atoms with classical negation as dele- 
tions of tuples. In particular, if a stable model M contains two atoms ~'p{t) 
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(derived atom) and p{t) (base atom) we deduce that the atom p{t) violates some 
constraint and, therefore, it must be deleted. 

The technique is sound and complete as each stable model defines a repair 
and each repair is derived from a stable model m- 

Consistent answers to queries against a possibly inconsistent database can be 
computed without modifying the database, on the basis of the stable models of 
the program corresponding to the integrity constraints and evaluated over the 
database. 

Definition 8. Given a database D, a set of functional dependencies IC and a 
query Q{g,V), the consistent answer of Q over D consists of the three distinct 
sets denoting, respectively, true, undefined and false atoms: 

- Ans+{Q,D,IC) = { g{t) G D | € SM{VV{TC),D) s.t. ~^g{t) G M } 

- Ans'^iQ.D.TC) = { g{t) G D \ 3Mi,M2 G SM{VV{TC),D) s.t. 

~'g{t) G Ml and -'git) ^ M 2 } 

- Ans~ iQ, D,IC) denotes the set of atoms which are neither true nor unde- 
fined (false atoms). □ 

The consistent answer to a query Q = [g^V) against a database D under 
the certain semantics is given by Ans~^{Q, D,IC). Analogously, the answer to 
Q = under the possible semantics constists in 

Ans+iQ,D,IC)[jAns'^iQ,D,IC). 

Observe that, true atoms appear in all repaired databases whereas undefined 
atoms appear in a proper subset of repaired databases. 

Theorem 1. Let D be an integrated database, XC be a set of functional depen- 
dencies and Q be a query, then the computation of a consistent answer ofQ ouer 
D can be done in polynomial time. □ 

Example J). Consider the integrated relation T of Example [T] and the functional 
dependency K {Title, Author, Year) stating that AT is a key for the relation. 
The functional dependency can be rewritten as first order formulas: 

(V®, y, z, w, y', z' , w') [T{x, y, z, w), T{x, y', z' , w')^y = y' , z = z',w = w'] 

The associated disjunctive program is 

-'Tix, y, z, w) V -iT(x, y' , z' , w') T(x, y, z, w),T{x, a,b,c),{y A aV z ^ bV w c) 

The above program has two stable models Mi = D U {-'r(3, Sky, Jones, 
1965)} and M 2 = DU{~<T{3, Flowers, Smith, 1965)}. Thus, the repairs for T are 
Ri — {{T{S, Flowers, Smith, 1965)},^) and R 2 = {{T {3, Sky, Jones, 1965)},^) 
producing, respectively, the repaired databases Ri{T) and i? 2 (T) reported in 
Figure [2l 

Finally, the answer to the query asking for the title of the book with code 2 
is Money whereas the answer to the query asking for the title of the book with 
code 3 is unknown since there are two alternative values. □ 
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Abstract. We describe here the last developments about NKRL (Narrative 
Knowledge Representation Language), a conceptual modeling formalism used 
to deal with ‘narrative’ multimedia documents. Narrative documents of an in- 
dustrial and economic interest correspond, e.g., to news stories, corporate 
documents, normative and legal texts, intelligence messages and medical rec- 
ords. A new Java version of NKRL, RDF- and XML-compliant, has been re- 
cently built-up in the framework of the CONCERTO Esprit project. 



1 Introduction 

Narrative documents, or ‘narratives’, are multimedia documents that describe the 
actual (or intended) state or behavior of some ‘actors’ (or ‘characters’, ‘personages’ 
etc.). These try to attain a specific result, experience particular situations, manipulate 
some (concrete or abstract) materials, communicate with other people, send or receive 
messages, buy, sell, deliver etc. Leaving pure fiction aside, we can note that: 

• A considerable amount of the natural language (NL) information that is relevant 
from an economic point of view deals with narratives. This is true for all the differ- 
ent sorts of news story documents, for most of corporate information (memos, pol- 
icy statements, reports, minutes etc.), for many intelligence messages, for medical 
records, notarized deeds, sentences and other legal documents, etc. 

• In the narrative documents, the actors or personages are not necessarily human 
beings. We can have narrative documents concerning, e.g., the vicissitudes in the 
journey of a nuclear submarine (the ‘actor’, ‘subject’ or ‘character’) or the various 
avatars in the life of a commercial product. This personification process can be 
executed to a very large extent, giving then rise to narrative documents very re- 
moved from a pure human context. 

• It is not even necessary that the narrative situations to deal with be recorded in NL 
documents. Let us consider a collection of Web images, where one represents an in- 
formation that, verbalized, could be expressed as “Three nice girls are lying on the 
beach”. Having at our disposals tools — like those described in this paper — for 
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coding the ‘meaning’ of narrative documents in a machine-understandable way, we 
can directly ‘annotate’ the picture without any recourse to a previous rendering in 
natural language. The same is, obviously, possible for ‘narrative’ situations de- 
scribed in video or digital audio documents. 

Being able to represent the semantic content of narratives — i.e., their key ‘mean- 
ing’ — in a general, accurate, and effective way is then both conceptually relevant and 
economically interesting. 

In this paper, we will describe the last developments concerning the use of NKRL 
(Narrative Knowledge Representation Language), see [1, 2, 3, 4], to represent the gist 
of economically relevant narratives. Note that NKRL has been used as ‘the’ modeling 
language for narratives in European projects like Nomos (Esprit P5330), Cobalt (LRE 
P61011) WebLearning (GALILEO Actions), and in the recent Concerto project (Es- 
prit P29159). In Concerto, NKRL was used to encode the ‘conceptual annotations’ 
(formal description of the main semantic content of a document) that must added to 
digital documents to facilitate their ‘intelligent’ retrieval, processing, displaying, etc. 
[5]. NKRL is now employed in the new Euforbia project (lAP P26505) to encode the 
rules used for filtering Internet documents according to a semantic-rich approach. 



2 General Information about NKRL 

Traditionally, the NKRL knowledge representation tools are presented as organized 
into four connected ‘components’, the definitional, enumerative, descriptive and fac- 
tual component. 

The definitional component supplies the tools for representing the ‘concepts’, in- 
tended here as the important notions that it is absolutely necessary to take into account 
in a given application domain. In NKRL, a concept is represented, substantially, as a 
frame-like data structure, i.e., as an n-ary association of triples ‘name-attribute-value’ 
that have a common ‘name’ element. This name corresponds to a symbolic label like 
human_being, taxi_ (the general class referring to all the possible taxis, not a 
specific cab) , city_, chair_, gold_, etc. NKRL concepts are inserted into a 
generalization/specialization hierarchy that, for historical reasons, is called 
H_CLASS(es), and which corresponds well to the usual ontologies of terms. The 
minimal requirements concerning a frame-based language suitable for playing the role 
of ‘definitional component’ in NKRL are expressed, e.g., in [1]. We will not dwell 
here on the H_CLASS (definitional component) characteristics given that the most 
‘interesting’ reasoning mechanisms of NKRL are associated with the descriptive and 
factual components, see below. The most used H_CLASS inferential mechanism is 
based simply on usual the generic/specific (subsumption) relationship among con- 
cepts, systematically employed, e.g., in all the NKRL applications for checking the 
constraints on the variables, see below. 

A fundamental assumption about the organization of the hierarchy of concepts in 
NKRL concerns the differentiation between ‘notions which can be instantiated directly 
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into enumerable specimens’, like “chair” (a physical object) and ‘notions which can- 
not be instantiated directly into specimens’, like “gold” (a substance). The two high- 
level branches of H_CLASS take origin, therefore, from two concepts labeled as 
sortal_concepts and non_sortal_concepts. The specializations of the 
former, like chair_, city_ or european_city can have direct instances 
(chair_27, paris_), whereas the specializations of the latter, like gold_ or 
colour_, admit further specializations, see white_gold or red_, but do not have 
direct instances. 

The ‘enumerative component’ of NKRL concerns the tools for the formal repre- 
sentation, as (at least partially) instantiated frames, of the concrete realizations 
(lucy_, taxi_53, chair_27, paris_) of the H_CLASS sortal concepts. 
In NKRL, the instances of sortal concepts take the name of individuals. Individuals are 
then countable and, like the concepts, possess unique symbolic labels (lucy_ etc.). 
Throughout this paper, I will use the italic type style to represent a concept_, the 
roman style to represent an individual_. Individuals, unlike concepts, are always 
associated with spatio-temporal co-ordinates that can, sometimes, refer to very hypo- 
thetical worlds, see, e.g., the individual green_f irespitting_dragon_4 9 . 
Note also that individuals do not have a proper hierarchical organization — instances 
of individuals are not allowed in NKRL, see [1]. They are nevertheless associated with 
the H_CLASS hierarchy, given that they appear as the ‘leaves’ of this hierarchy, di- 
rectly linked with the sortal concepts. Assuming then the existence, in a particular 
NKRL application, of a database of individuals, this last can be considered as indexed 
by the H_CLASS hierarchical structure. 

The ‘descriptive’ and ‘factual’ tools concern the representation of the ‘events’ 
proper to a given domain — i.e., the coding of the interactions among the particular 
concepts and individuals that play a role in the contest of these events. 

The descriptive component includes the modeling tools used to produce the formal 
representations (called ‘templates’) of some general narrative classes, like “moving a 
generic object”, “formulate a need”, “having a negative attitude towards someone”, 
“be present somewhere”. In contrast to the traditional frame structures used for con- 
cepts and individuals, templates are characterized by the association of quadruples 
connecting together the symbolic name of the template, a predicate and the arguments 
of the predicate introduced by named relations, the roles. The quadruples have in 
common the ‘name’ and ‘predicate’ elements. If we denote then with L the generic 
symbolic label identifying a given template, with the predicate used in the template, 
with Rj the generic role and with a^ the corresponding argument, the NKRL data 
structures for templates have the following general format: 

(L(P,(R,a,)(R,a,)...(R a„))), ( 1 ) 

see the example in Figure 1, commented below. Presently, the predicates pertain to the 
set {BEHAVE, EXIST, EXPERIENCE, MOVE, OWN, PRODUCE, 

RECEIVE}, and the roles to the set (SUBJ(ect), OBJ(ect), SOURCE, 
BEN (e) F (iciary) , MODAL (ity), TOPIC, CONTEXT}. 
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Templates are structured into an inheritance hierarchy, H_TEMP(lates), which cor- 
responds, therefore, to a new sort of ontology, an ‘ontology of events’. 

The instances (called ‘predicative occurrences’) of the templates, i.e., the repre- 
sentation of single, specific elementary events — see examples like “Tomorrow, I will 
move the wardrobe” or “Lucy was looking for a taxi” — are, eventually, in the do- 
main of the last component, the factual one. Predicative occurrences are always asso- 
ciated with the indication of the temporal interval where the corresponding elementary 
event ‘holds’. The interval is delimited by two ‘timestamps’ <t^, tp> such that tj<t^ — 
the meaning of ‘<’ is here intuitive. A detailed description of the ‘theory’ of temporal 
representation in NKRL can be found in [2] . 



3 A Simple Example 

To represent an elementary event like “On April 5th, 1982, Francis Pym is appointed 
Foreign Secretary by Margaret Thatcher” under the form of predicative occurrence 
(factual component), we must select firstly the template corresponding to ‘nominate to 
a post’ , which is represented in the upper part of Figure 1 . 

The ‘position’ code shows the place of this ‘nomination’ template within the OWN 
branch (5.) of the H_TEMP hierarchy, see also Figure 2: this template is then a spe- 
cialization (see the ‘father’ code) of the particular OWN template of H_TEMP that 
corresponds to ‘being in possession of a post’ . The (mandatory) presence of a ‘tempo- 
ral modulator’, ‘begin’ indicates that the only timestamp (f^) which can be associated 
with the predicative occurrences derived from the ‘nomination’ template corresponds 
to the beginning of the state of being in possession — here, to the nomination. In the 
occurrences, time stamps are represented through two ‘temporal attributes’, date-1 
and date- 2, see [2]. In the occurrence cl of Figure 1, this interval is reduced to a 
point on the time axis, as indicated by the single value, ‘5-april-1982’ (the nomi- 
nation date), associated with the attribute date-1. 

The argument of the predicate (the a^ terms in formula ( 1 ) of the previous Section) 
are represented by variables with associated constraints; these last are expressed as 
concepts or combinations of concepts, i.e., making use of the terms of the H_CLASS 
hierarchy (definitional component). The arguments associated with the SUBJ (ect ) , 
OBJ (act), SOURCE and BEN (e) F (iciary) roles can be further specified by 
denoting the ‘place’ (location) they occupy within the framework of a particular event. 
For example, we could add that, at the time of the nomination, both Francis Pym and 
Margaret Thatcher were in London. These ‘location attributes’ — represented by the 
variables var2 and var5 in the template of Figure 1, and implemented as lists in 
the predicative occurrences, see, e.g., occurrence c3 in Figure 3 below — are linked 
with the predicate arguments by using the colon operator, The constituents (as 
SOURCE in Figure 1) included in square brackets are optional; the symbol { } * means 
that a constituent is forbidden for a given template. 

The role fillers in the predicative occurrence represented in the lower part of Figure 
1 conform to the constraints of the father- template. For example, francis_pym is 




A Knowledge Engineering Approach to Deal with ‘Narrative’ Multimedia Documents 



367 



an individual (enumerative component) instance of the sortal concept individ- 
ual_person that is, in turn, a specialization of human_being-, for- 
eign_secretary is a specialization of post_, etc. — note that the filler of a 
SOURCE role always represents the ‘originating factor’ of the event. 



name: Own : NamingToPost 

father: Own : BeingInPossessionOfPost 

position: 5.1221 

NL description: 'A Human Being is Appointed to a Post' 



OWN 



SUBJ 


varl : 


1 ( var2) 


OBJ 


var3 




[SOURCE 

{BENE}* 


var4 : 


[ ( var5) 


[MODAL 


var6] 




[TOPIC 


varl] 




[CONTEXT 


var8] 





{ [ modulators ] , begin } 



varl = 
var3 = 
var4 = 
var6 = 
varl = 
var8 = 
va r2 , var5 



<human_be ing> 

<post_> 

<human_being_or_social_body> 
<act ion_name> 

<property_> 

<event_> | <action_name> 
<physical_location> 



cl) OWN SUBJ francis_pym 

OBJ foreign_secretary 

SOURCE margaret_thatcher 
[begin] 

date-1: ( 5-april-l 982 ) 

date-2 : 



Fig. 1. Deriving a predicative occurrence from a template 

We can note an important point. Unlike, e.g., canonical graphs in Sowa’s concep- 
tual graphs theory, see [6], which must be explicitly defined for each new application, 
the (about 200) templates that make up actually the H_TEMP hierarchy are fixed and 
fully defined — H_TEMP corresponds then to a sort of ‘catalogue’ of NKRL tem- 
plates, and we can say that these templates are part and parcel of the definition of the 
language. An (extremely simplified) image of the present H_TEMP hierarchy is given 
in Eigure 2. Note that, when needed, it is easy to derive from the existing templates 
new templates that it could be required for a particular application. H_TEMP is then a 
growing structure. On the other hand, H_TEMP can be customized by making use of a 
‘sub-catalogue’ including only the templates strictly relevant to a given domain. 
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H TEMP 



1. Behave: 2. Exist: 3. Experience: 4. Move: 5. Own: 6. Produce: /.Receive: 



3.5 Experience:VaiuedEvents 



3.51 Experience: PositiveEvents 

3.52 Experience: NegativeEvents 



7.1 Receive: MateriaiThing 



7.11 Receive: GetMoney 



5.1 Own:BeinPossession 5.2 Own:Property 

, ^ , 

5.11 Own:BeinPossessionOfPost 5.13 Own:Controi 

I I 

5.111 Own:NamingToPost I 



1 



5.131 Own:ControiOfMarket 



4. Move: 



5.132 Own:ControiOfSociaiBody 



5.1321 Own:ControiOfCompany 



4.1 Move:MoveEntity 4.2 Move:TransferToSomeone 



I 

4.11 Move: MateriaiThing 

4.12 Move: CompiexStructure 

4.13 Move:ChangeOfState 
4.131 Move:TransformProduct 



4.4 Move:Transmitlnformation 

I 

4.41 Move:Genericlnformation 
4.42 Move:Structuredlnformation 



4.3 Move:GenericDispiacement 



423 Move:TransferOfResource Move.ChangeOfActivity 

I 



4.231 Move: TransferOfService 

I 

4.2311 Move:Version/PartOfService 



Fig. 2. A (simplified) picture of the H_TEMP hierarchy (descriptive component) 
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This approach is particularly advantageous for practical applications, and it im- 
plies, in particular, that: i) a system-builder does not have to create himself the struc- 
tural knowledge needed to describe the events proper to a (sufficiently) large class of 
narrative documents; ii) it becomes easier to secure the reproduction or the sharing of 
previous results. Expressed in different terms, we can say that the NKRL approach 
implies the addition of an ‘ontology of events’, H_TEMP, to the traditional ‘ontology 
of concepts’, H_CLASS, augmenting then greatly the global interoperability of the 
language. 



4 Additional Properties of the NKRL Language 

The basic NKRL tools are enhanced by two additional classes of conceptual struc- 
tures: 

• the AECS ‘sub-language’, see [7], that allows the construction of complex (struc- 
tured) predicate arguments, called ‘expansions’; 

• the second order tools (binding structures and completive construction), see [2], 
used to Lcode the ‘connectivity phenomena’ (logico-semantic links) that, in a nar- 
rative situation, can exist between single narrative fragments (corresponding to sin- 
gle NKRL predicative structures). 

We will introduce informally the two new tools making use of additional examples 
of NKRL coding of narrative structures. Ligure 3 translates then this fragment of news 
story: “This morning, the spokesman said in a newspaper interview that, yesterday, his 
company has bought three factories abroad”. today_ and yesterday_ are two 
fictitious individuals introduced here, for simplicity’s sake, in place of real or ap- 
proximate dates, see [2]. Note that the arguments of the predicate, and the tem- 
plates/occurrences as a whole, may be characterized by the presence of particular 
codes, determiners or attributes (like the ‘temporal modulators’ introduced in the pre- 
vious Section), which give further details about their significant aspects. Lor example, 
as already noticed, the location attributes, represented as lists, are linked with the 
arguments by using the colon operator, see c 3 in Ligure 3 (abroad_). 

The ‘attributive operator’, SPECIF (ication) , which appears in both the occur- 
rences c2 and c3, is one of the four operators that make up the AECS sub-language. 
AECS includes the disjunctive operator (ALTERNative = A), the distributive op- 
erator (ENUMeration = E), the collective operator (COORDination = C), and the 
attributive operator (SPECIFication = S). 

The meaning of ALTERN (ative) is self-evident. Informally, the semantics of 
SPECIF (ication) can be explained in this way: the SPECIF lists, with syntax 
(SPECIF ... p^) , are used to represent some of the properties p^ that can 

be asserted about the first argument e^, concept or individual, of the operator, e.g., 
human_being_l and spokesman_ in the occurrence c2 of Ligure 3. 
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In a COORD (ination) list, all the elements of the expansion take part — neces- 
sarily together — in the particular relationship with the predicate defined by the role 
to be filled; in an ENUM (eration) framework, this simultaneity is not required. As 
an example, we can imagine a situation where the spokesman has communicated his 
information to two different newspapers, newspaper_l and newspaper_2, the 
BEN (e) F (iciaries) — BENF is the role to be filled. If the two newspapers have 
assisted together to the interview, i.e., if they have received the information together, 
then the BENF slot of c2 will be filled with (COORD newspaper_l newspa- 
per_2) . On the contrary, if the information was received separately — which can 
correspond, in practice, to a situation where the newspapers have taken part in two 
different interviews — then the BENF filler becomes: (ENUM newspaper_l 
newspaper_2). ENUM can then be considered as a shortcut for reducing the size of a 
database of predicative occurrences by merging quite similar occurrences. For more 
information about the AECS operators and, in particular, about the rules for mixing 
them within the same expansion (‘priority rule’), see [2]. 



c2) MOVE SUBJ 

OBJ 
BENF 
MODAL 
date-1 : 
date-2 : 



(SPECIF human_being_l 

(SPECIF spokesman_ company_l) ) 

#c3 

newspaper_l 

interview_ 

today_ 



c3) PRODUCE SUBJ company_l 

OBJ (SPECIF purchase_l (SPECIF factory_99 

(SPECIF cardinality_ 3))): (abroad_) 

date-1: yesterday_ 
date-2 : 



[ factory_99 

InstanceOf : factory_ 
HasMember : 3 ] 



Fig. 3. An example of completive construction 

The last item of Figure 3 supplies an example of enumerative data structure, ex- 
plicitly associated with the individual factory_99 according to the rules for coding 
‘plural situations’ in NKRL, see [1]. The non-empty HasMember slot in this structure 
makes it clear that the individual factory_99, as mentioned in c3, is referring in 
reality to several instances of factory_. Individuals like factory_99 are ‘collec- 
tions’ rather then ‘sets’ (all the NKRL concepts can be interpreted as sets), given that 
the extensionality axiom (two sets are equal iff they have the same elements) does not 
hold here. In our framework, two collections, say factory_9 9 and fac- 
tory_10 0, can be co-extensional, i.e., they can include exactly the same elements, 
without being necessarily considered as identical if created at different moments in 
time in the context of totally different event, see [8]. In Figure 3, we have supposed 
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that the three factories were, a priori, not sufficiently important in the context of the 
news story to justify their explicit representation as specific individuals, e.g., fac- 
tory_l, factory_2, factory_3. Note that, if not expressly required by the 
characteristics of the application, a basic NKRL principle suggests that we should try 
to avoid any unnecessary proliferation of individuals. 

In coding narrative information, one of the most difficult problems consists in being 
able to deal (at least partly) with the ‘connectivity phenomena’ like causality, goal, 
indirect speech, co-ordination and subordination, etc. — in short, all those phenomena 
that, in a sequence of statements, cause the global meaning to go beyond the simple 
addition of the information conveyed by each single statement. In NKRL, the connec- 
tivity phenomena are dealt with making a (limited) use of second order structures: 
these are obtained from a reification of the predicative occurrences that is based on the 
use of their symbolic labels — like c2 and c3 in Figure 3. A first example of second 
order structure is given by the so-called ‘completive construction’, that consists in 
accepting as filler of a role in a predicative occurrence the symbolic label of another 
predicative occurrence. For example, see Figure 3, we can remark that the basic, 
MOVE template (descriptive component) that is at the origin of c2 is systematically 
used to translate any sort of explicit or implicit transmission of an information (“The 
spokesman said...”). In this example of completive construction, the filler of the 
OBJ (ect) slot in the occurrence (c2) which materializes the ‘transmission’ template 
is a symbolic label (c3) that refers to another occurrence, i.e. the occurrence bearing 
the informational content to be spread out (“ ...the company has bought three factories 
abroad”). 

Figure 4 corresponds now to a narrative information that can be rendered in natural 
language as: “We notice today, 10 June 1998, that British Telecom will offer its cus- 
tomers a pay-as-you-go (payg) Internet service”. 



c4 ) 


(GOAL 


c5 c6) 




c5 ) 


BEHAVE 
{ obs 


SUBJ 

} 


british_telecom 




datel : 
date2 : 


10- june-1998 


*c6) 


MOVE 


SUBJ 
OBJ 
BENE 
datel : 
date2 : 


british_telecom 
payg_internet_service_l 
(SPECIF customer_ british_telecom) 
after-lO-june-1998 



Fig. 4. An example of binding occurrence 



To translate the general idea of ‘acting to obtain a given result’, we use then: 
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• A predicative occurrence (c5 in Figure 4), instance of a basic template pertaining 
to the BEHAVE branch of the template hierarchy (H_TEMP), and corresponding to 
the general meaning of ‘focusing on a result’ . This occurrence is used to express the 
‘acting’ component, i.e., it allows us to identify the SUBJ (ect ) of the action, the 
temporal co-ordinates, possibly the MODAL ( ity ) or the instigator (SOURCE), etc. 

• A second predicative occurrence, c 6 in Figure 4, with a different NKRL predicate 
and which is used to express the ‘intended result’ component. This second occur- 
rence, which happens ‘in the future’ with respect to the previous one (BEHAVE), is 
marked as hypothetical, i.e., it is always characterized by the presence of an uncer- 
tainty validity attribute, code ‘*’. Expressions like after-lO-june-1998 are 
concretely rendered as date ranges, see [2] . 

• A ‘binding occurrence’, c4 in Eigure 4, linking together the previous predicative 
occurrences and labeled with GOAL, an operator pertaining to the taxonomy of cau- 
sality of NKRL, see [2]. 

Binding structures — i.e., lists where the elements are symbolic labels, c5 and c6 
in Eigure 4 — are another example of second-order structures used to represent the 
connectivity phenomena. The general schema for representing the ‘focusing on an 
intended result’ domain in NKRL is then; 

cj (GOAL Cp c^) 

Cp) BEHAVE SUBJ <human_being_or_social_body> 

*c^ <predicative_occurrence, with any syntax> . 

In Eigure 4 ‘obs (erve) ’ is, like ‘begin’ and ‘end’, a temporal modulator, see 
[2]. ‘ obs’ is used to assert that the event related in the occurrence ‘holds’ at the date 
associated with date-1 without, at this level, giving any detailed information about 
the beginning or end of this event, which normally extends beyond the given date. 
Note that the addition of a ‘ment (al) ’ modulator in the BEHAVE occurrence, Cp, 
which introduces an ‘acting to obtain a result’ construction should imply that no con- 
crete initiative is taken by the SUBJ of BEHAVE in order to fulfil the result. In this 
case, the ‘result’, *c^, reflects only the wishes and desires of the SUBJ (ect) . 



5 Implementation Notes 

A new version of NKRL, implemented in Java and XML/RDE compliant, has been 
realized in the CONCERTO’S framework. We recall here that the RDE model, see [9, 
10], is a framework for describing general-purpose metadata that is promoted by the 
W3C Committee and is based on XML. In knowledge representation terms, the basic 
RDE data structure can be assimilated to a triple where two ‘resources’ are linked by a 
‘property’ that behaves like a dyadic conceptual relation. A description of some prob- 
lems encountered when translating into RDE the NKRL data structures, and of the 
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solutions adopted in this context, can be found in [3, 4]. These problems have con- 
cerned mainly i) the correct representation of the NKRL variables and of their con- 
straints; ii) the rendering in RDF of Ihtfour AECS operators making use only of three 
RDF ‘containers’, ‘Bag’, ‘Sequence’ and ‘Alternative’. In Figure 5, we reproduce the 
native NKRL coding (above) and the NKRL/RDF CONCERTO coding (below) of an 
extremely simple narrative fragment; “On June 12, 1997, John and Peter were admit- 
ted (together) to hospital” — note that adding the indication ‘together’ forces an inter- 
pretation in a COORD style. Note also that, in the RDE coding, the COORD list that 
represents the filler of the SUBJ role in NKRL is rendered as a Bag, see [9]. 



cl) EXIST SUBJ (COORD john_ peter_) : (hospital_l) 

{ begin } 

date-1: 2-june-1997 
date-2 : 

<?xml version=" 1 . 0 " ?> 

CDOCTYPE DOCUMENTS SYSTEM " CA_RDF . dtd" > 

<CONCEP TUAL_ANNOTAT 1 0N> 

<rdf:RDF x mlns : rdf="t^rp ■ / /www m-g /1 QQQ / n? / 7 7-r-ri-F-Bynr 
xmlns : rdf="ll^tp ■ / /www nrg/TR /1 qqq /PR-rHf-^rhg^ma-l 
xmlns :ca=" http://projects.pira.co.Uk/concerto#"> 

<rdf : Description about="occ7 " > 

<rdf : type resource="ca : Occurrence" /> 

<ca : instanceOf >Template2 . 31</ ca : instanceOf > 

<ca : predicateName>Exist</ ca : predicat eName> 

<ca: subject rdf : ID="Sub j2 . 31" rdf : parseType="Resource"> 
<concerto : f iller> 

<rdf : Bag> 

<rdf :li rdf : resource=" # john_" /> 

<rdf : li rdf : resource=" #peter_" /> 

</rdf : Bag> 

</concerto:filler> 

<concerto : location>hospital_l</ concerto : location> 

</ ca : sub ject> 

<ca : listOfModulators> 

<rdf : SeqXrdf : li>begin</rdf : lix/rdf : Seq> 

</ca : listOfModulators> 

<ca : datel>02 / 06/1997</ca: datel> 

</ rdf : Description> 

</rdf :RDF> 

</CONCEPTUAL_ANNOTATION> 



Fig. 5. RDF/XML representation of a simple NKRL predicative occurrence 
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To supply now some details about the query and inferencing operations proper to 
NKRL, let us introduce informally the concept of ‘search pattern’. Search patterns — 
i.e., the formal counterparts of natural language queries — are NKRL data structures 
that correspond to partially instantiated templates and that supply the general frame- 
work of information to be searched for, by filtering or unification, within an NKRL 
knowledge base. A simple example of search pattern, translating the query: “Was John 
at the hospital in July/ August 1997?” (see the upper part of Figure 5) is represented in 
Figure 6. The two timestamps associated with the pattern constitute now the ‘search 
interval’ that is used to limit the search for unification to the slice of time that it is 
considered appropriate to explore. In our example, the search pattern of Figure 6 can 
successfully unify occurrence c7 in Figure 5: in the absence of explicit, negative evi- 
dence, a given situation is assumed to persist within the immediate temporal environ- 
ment of the originating event, see [2]. 



(?w IS-PRED-OCCURRENCE 

:predicate EXIST 

:SUBJ john_ 

: location of SUBJ hospital_ 
(l-july-1997, 31-august-1997) ) 



Fig. 6. A search pattern that unifies the predicative occurrence of Figure 5 

In the CONCERTO version of NKRL, a Java module called FUM module (Filter- 
ing Unification Module) deals with search patterns. Unification is executed taking into 
account, amongst other things, the fact that a ‘generic concept’ included in the search 
pattern can unify one of its ‘specific concepts’ — or the instances (individuals) of a 
specific concept — included in a corresponding position of the occurrence. ‘Generic’ 
and ‘specific’ refer, obviously, to the structure of the NKRL concept ontology, i.e., 
H_CLASS. Therefore, a search pattern asking which company has proposed a pay-as- 
you-go (payg) Internet service to his customers will retrieve the predicative occur- 
rence c6 of Figure 4, given that the SUBJ filler of the pattern, company_, sub- 
sumes in H_CLASS telecom_company, and the individual british_telecom 
in Figure 4 is an instance of telecom_company. From an algorithmic point of 
view, the main interest of FUM lies in the operations needed to unify correctly the 
complex fillers built up making use of the four AECS operators. These imply the de- 
composition of the complex fillers into tree structures labeled with the operators, and 
in the unification of the tree structures of the pattern with those of the occurrences 
following the priorities defined by the ‘priority rule’ already mentioned, see [2, 7]. 

The inference level supplied by EUM is only a first step towards more complex 
reasoning strategies. Eor example, the use of the ‘transformation rules’ allows to deal 
with the problem of obtaining a plausible answer from a database of predicative occur- 
rences also in the absence of the explicitly requested information, by searching se- 
mantic affinities between what is requested and what is really present in the repository. 
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The principle employed consists in using these rules to automatically ‘transform’ the 
original query (i.e., the original search pattern) into one or more different queries 
(search patterns) that are not strictly ‘equivalent’ but only ‘semantically close’ to the 
original one, see [11]. 

We will now supply some information about another category of NKRL inference 
rules, the ‘hypotheses’, see the example of Figure 7. 



Premise : 



RECEIVE SUBJ X 

OBJ money_ 

SOURCE y 

X = company_ 

y = human_being \ company_ 

“A company has received some money from another company or a physical person” 

First condition schema : 



PRODUCE SUBJ 

OBJ 
BENE 
TOPIC 

z = mutual_commitment 
V = tool/product_ 



(COORD X y) 
z 

(COORD X y) 

(SPECIF process_ v) 

business_agreement 



“A general of business-oriented agreement about the creation of a new product has been con- 
cluded by the two parties mentioned in the premise” 



Second condition schema : 



PRODUCE 


SUBJ 


X 




OBJ 


V 




MODAL 


w 




CONTEXT 


z 



w = industrial process \technological_process 

“The company that received the money has actually created the product mentioned in the first 
condition schema” 



Fig. 7. An example of hypothesis rule 
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We suppose here to have directly retrieved, thanks to FUM, a given information 
within a base of NKRL occurrences, e.g., the information: “Pharmacopeia, an USA 
biotechnology company, has received 64,000,000 dollars from the German company 
Sobering in connection with an R&D activity”. We suppose, moreover, that this occur- 
rence is not already explicitly related with other occurrences of the base. Under these 
conditions, we can activate a specific Java module, InferenceEngine that, using a rule 
like that of Figure 7, will try to rely automatically the information found originally by 
FUM with other information in the base. If this is possible, this last information will 
represent a sort of ‘causal explanation’ of the information originally retrieved — in 
our example, an ‘explanation’ of the money paid by Sobering. In our example, we will 
find, e.g., that “Pharmacopeia and Sobering have signed an agreement concerning the 
production by Pharmacopeia of a new compound” and that “In the framework of the 
agreement previously mentioned. Pharmacopeia has actually produced the new com- 
pound”. 



6 Conclusion 

In this paper, we have described the last developments of NKRF (Narrative Knowl- 
edge Representation Fanguage), a conceptual modeling formalism used for taking into 
account the characteristics of narrative documents. In these documents, the main part 
of the information content consists in the description of ‘events’ that relate the real or 
intended behavior of some ‘actors’ (characters, personages, etc.). Narrative documents 
of an industrial and economic interest correspond, for example, to news stories, corpo- 
rate documents (memos, policy statements, reports and minutes), normative and legal 
texts, intelligence messages, representation of the patient's medical records, etc. 
NKRL makes use of several representational principles (concepts under the form of 
frames, templates, second order binding structures etc.) and of several high-level in- 
ference tools. Some information on the implementation aspects (and on the inference 
techniques) has also been supplied in the paper. 
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Abstract. The aim of this paper is to present a brief outline of a fur- 
ther step in the ongoing work concerning the hyper-set-theoretic ap- 
proach to (unstructured) distributed Web-like databases and correspond- 
ing query language A. The novel idea in this paper consists in using dy- 
namically created mobile agents (processes) for more efficient querying 
such databases by exploiting concurrently distributed computational re- 
sources, potentially over the whole Internet. A fragment of a calculus of 
querying agents based on A is presented. 



1 Introduction 

Querying and searching the World-Wide Web (WWW) or, more generally, un- 
structured or Web-like Databases (WDB) is one of the most important contem- 
porary information processing tasks. There are several search engines such as 
Alta Vista, Lycos, etc., but their search can hardly be characterised as “goal- 
directed” and always “up to date” . Also it is desirable not only to be able to find 
a list of Web-pages of potential interest, but to ask more complex queries allow- 
ing, additionally, reorganisation of Web data, as required. That is, the answer to 
a query should constitute a number of possibly newly created hyper-linked pages 
(re) constructed from some pages existing somewhere in WDB — very much in 
the same way as in a relational database. A new relation/WDB-page(s) (the 
answer to a query) is the result of reconstructing existing ones in the database. 
In fact, our approach to WDBs is a natural generalisation of the traditional re- 
lational databases and differs essentially from the other known considerations of 
semi-structured databases, being actually (hyper) set-theoretic one. 

The starting point for this work was the characterisation of PTIME com- 
putability in terms of recursion over finite structures obtained by the author 
[32] and independently by N. Immerman, A. Livchak, M. Vardi and Y. Gurevich 
[18,20,26,42,18]. It should be mentioned, of course, the seminal previous work of 
R. Fagin [14] on describing NPTIME in terms of existential second-order logic. 



D. Bj0rner, M. Broy, and A. Zamulin (Eds.): PSI 2001, LNCS 2244, pp. 378—394, 2001. 
(c) Springer- Verlag Berlin Heidelberg 2001 




Using Agents for Concnrrent Querying of Web-Like Databases 379 



Such results were also considered in a framework of an abstract approach to 
query languages for relational databases. The subsequent work of the author on 
Bounded Set Theory [33,34,36,23,22] is a natural continuation and generalisation 
of these results for the case of more flexible structures such as hereditarily-finite 
sets which are more suitable for providing mathematical foundations of complex 
or nested databases. Later these considerations absorbed, in [35], the idea of non- 
well-founded set (or hyper-set) theory introduced by P. Aczel [3]. This made the 
approach potentially applicable to (possibly distributed) semistructured or Web- 
like databases [24,25,37] with allowing cycles in hyper-links. Using distributed, 
dynamically created agents for more efficient querying of such databases by ex- 
ploiting concurrently distributed computational resources (potentially over the 
whole Internet) is a further step to be developed within this framework. 

Note, that our work is not intended to working out a general theory of agents. 
They are rather a tool for achieving efficiency in the querying process. However, 
an intermediate task consists of developing a new (or adapting some previously 
known) theory or calculus of agents suitable to our considerations. (Cf. references 
at the end of Section 4.) In this short paper we can only outline the main (es- 
sentially inseparable) ideas: hyper-set approach to WDB and to querying WDB, 
and using agents (in the context of this hyper-set framework). Also, in spite of 
any declared allusion to reality of WWW, which seems very useful and thought 
provoking, the present paper is highly abstract (and simultaneously informal and 
sketchy in some respects). But the author believes that the level of abstraction 
chosen is quite reasonable. The goal is not WWW itself, but some very general 
ideas around set-theoretic approach to WDB. 

Our plan is as follows. Sect. 2 outlines the hyper-set approach to WDB. 
Sect. 3 is devoted to a brief but quite precise presentation of a hyper-set A- 
language and its extensions for querying WDB. Sect. 4 discusses informally using 
agents for concurrent and distributed querying WDB. Then a fragment of a 
calculus of agents for computing Z\-queries (a preliminary semiformal version) 
in Sect. 5 is presented. Finally, a Conclusion briefly summarises the whole paper. 



2 An Outline of Hyper-Set Approach to WDB 

The popular idea of a semi- (or un-) structured data base which, unlike a re- 
lational database, has no rigid schema, has arisen in the database community 
rather recently (cf. e.g. [1,2,7,27,8]), particularly in connection with the Internet. 
These databases can also be naturally described as Web-like databases (WDB) 
[24,25,37,38,39]. The best example of such a database is the World-Wide Web 
itself understood as a collection of Web-pages (html-files) distributed by various 
sites over the world and arbitrarily hyper-linked. 

We adopt here a deliberately simplified, very abstract picture which, however, 
involves the main feature of WWW as based on hyper-links between URLs^ 

^ Recall that in WWW URL = Uniform Resource Locator, i.e. address of a WWW- 
page (a specific html-file) on a Web-server. 
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of the Web-pages distributed potentially over the world. Having in mind set- 
theoretical approach to semistructured databases (arisen quite independently of 
WWW in [33] or, in somewhat different framework, [9,10]) and contemporary 
ideas on semistructured databases (cf. op. cit.), we consider that the visible part 
of a WDB-page, Page('u), with the URL u is a (multi)set {]/i, ^ 2 , ■ • • , ^fc[l' of words 

li (rather than a sequence or list {h, I 2 , ■ ■ ■ , h)) where u Vi represent all the 
outgoing hyper-links from u to Vi. The URLs Vi are considered as non-visible 
part of the page Page(u) = {^i : vi, I 2 '■ V 2 , ■ ■ ■ ,lk '■ Vk} (a set of pairs of the kind 
label : URL — an abstraction from an html file). Both h and corresponding Vi 
are present in this page having the URL u, but in the main window of a browser 
we do not see the URLs vp, u being shown outside the window. Their role is very 
important for organisation of the information in WDB via addressing /hyper- 
linking but quite different from that of the words U, the latter carrying the 
proper information. All words U on a Web-page are considered as (names or 
labels of) hyper-links, possibly trivial ones (e.g. links to an empty or non-existing 

page) . By analogy with WWW we could underline if m -4- Vi and Vi is “non- 
empty”, i.e. there exists at least one hyper-link Vi ^ w outgoing from Vi (and it 
therefore makes sense to “click” on h to see all these m). 

Such Web-like databases are evidently represented as directed graphs with la- 
belled edges (or labelled transition systems), the labels I serving as the names of 

hyper-links or references m -4 w between graph vertices (URLs) u and v. Equiv- 
alently, WDB may be defined a finite subset of URL x Label x URL. As in any 
database, a query language and corresponding software querying system are 
needed to properly query and retrieve the required information from a WDB. 

In principle, for intermediate theoretical goals, it makes sense to consider also 
simplified “label-free” , “pure” framework with simple unlabelled hyper-links u — >■ 
V and (corresponding oversimplified) WDB is just an arbitrary finite (directed) 
graph with Edges — URLs. Then WDB-page Page(r() with a URL u is just a 
set of URLs {ui, . . . ,Uk} such that vi are all outgoing edges from u. 

Let us assume additionally that each graph vertex (URL) u refers both to a 
site Site(w) G SITES where the corresponding WDB-page is saved as an (html) 
file and to this WDB-page itself. Some URLs may have the same site: Site(ui) = 
Site(rt 2 ). However it is not the most interesting case, it is quite possible when 
there exists only one site for the whole (in this case non-distributed) WDB. 

In the hyper- set- theoretic approach adopted here each graph vertex u (URL 
[24,37], called also object identity, Oid, [1,2,7]) is considered as carrying some 
information content (|u[) — the result of some abstraction from the concrete 
form of the graph. In principle, two Web-pages with different URLs ui and U 2 
may have the same {hereditarily, under browsing starting from ui and U 2 ) visible 
content. This is written as (]ui[) = (U 2 ) or, equivalently, as u\ ~ U 2 where ~ 
is a bisimulation equivalence relation on graph vertices (which can be defined 
in graph-theoretic terms [3] independently of any hyper-set theory). Somewhat 
analogous considerations based on a bisimulation relation are developed in [7], 
but the main idea of our approach consists not only in respecting the bisim- 
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ulation (or, actually, informational equivalence) relation, but in “considering” 
graph vertices as abstract sets (m[) within hyper-set theory [3]: 

(|u[) = {/ : (u[) I WDB has a labelled hyper-link u u}. (1) 

or in the simplified, “pure, label-free” semantics: 

(m[) = {(wD I WDB has a hyper-link u — >■ u}. (2) 

Thus, (\u\) is a (hyper-) set of all labelled elements I : (u) (also hyper-sets, 

etc.) such that WDB has a hyper-link u \ v. This (actually uniquely satisfying 
(1)) set-theoretic denotational semantics of graph vertices has evidently a com- 
plete agreement with the meaning of the equality (ui) = (|u 2 |) or bisimulation 
equivalence u\ ~ U 2 briefly mentioned above. (Cf. details in [35,24,25,37].) 

Unlike the ordinary (Zermelo-Frenkel) set theory, cycles in the membership 
relation are here allowed. Hence, a simplest such “cycling” set is 17 = {17} con- 
sisting exactly of itself. Such sets must be allowed because hyper-links (in a WDB 
or in WWW) may in general comprise arbitrary cycles. We have crucial theoret- 
ical benefits from this hyper-set framework by using well understood languages 
(like A formally presented in Sect. 3) and ideas. Hyper-sets arising from graph 
vertices via (1) are quite natural and pose no essential conceptual difficulty. 
Returning to the graph view, querying of a WDB may be represented as 

— starting on a local site s (where the query q{u) is evaluated) from an initial 
or input URL u of a page (saved as an html file on any remote site Site(w)); 

— browsing page-by-page via hyper- links (according to the query q)\ 

— searching in pages arising in this process (according to the query q); 

— composing new (auxiliary — for temporary intermediate goals — or final) 
hyper-linked pages with their URLs (on the basis of the previous steps) with 
one of these pages declared as main answer or resulting (output or “title”) 
page for the query; 

— all of this may result in reorganising of the data (at least locally on s by 
auxiliary pages located and hyper- linked between themselves and externally) . 

Of course, the user could habitually do all this job by hands. However, it is more 
reasonable to have corresponding implemented query language and system which 
would be able to formally express and evaluate any query q. This essentially 
differs from the ordinary search engines such as Alta Vista or Lycos, etc. Here 
we can use the advantages of our set theoretic view and of the corresponding 
language A [34,36,24,25], at least theoretically. 

Again, the key point of our approach consists in co-existing and inter- 
playing two natural and related viewpoints for such a query q: graph- and set- 
theoretic ones. The above described steps result in some transformation (es- 
sentially a local extension by new pages) of the original WDB (WWW) graph. 
Usually, in semistructured databases arbitrary graph transformations are allowed 
[1,2]. But if this process respects the information content (u) of the input WDB 
vertices (URLs) u then it should be restricted to be bisimulation invariant (as it 
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was done also independently in [7], but without a sufficient stress on set theory) 
and therefore it could be also considered as a set theoretic operation q, i.e. 

q : d input URL) i — >• (| output URL) = g(| input URL). 

Originally, this approach arose exactly as a set-theoretical view [33,34] with (at 
that time acyclic) graphs representing the ordinary or well-founded hereditarily- 
finite sets whose universe is denoted as HF ^ [6]. Any database state may be 
considered as a set of data each element of which is also a further set of data, 
etc. (with always finite depth of nesting which is equal 4 in the case of a “flat” 
relational database). A generalised universe of anti-founded hereditarily-finite 
(hyper) sets is called HFA, and any query is considered as a map (set-theoretic 
operation — a well understood concept) q : HF — >■ HF or q : HFA — >■ HFA. 

A (version of) purely set-theoretic query language A allowing expression of 
queries g to a WDB has been developed (with a natural and simplest syntax 
whose main feature is the use of hounded quantifiers \/x € t and 3x € t and other, 
essentially bounded, constructs; cf. e.g. [35,36,25,24] and Sect. 3 below for the 
details). This language has two kinds of semantics in terms of: (i) set-theoretic 
operations q over HFA (such us set union or “concatenation” of WDB-pages), 
etc. — a high level semantics for humans) and (ii) corresponding graph (WDB) 
transformers Q — (a lower level semantics for program implementation), with 
a commutative diagram (3) witnessing that both semantics agree 

HFA HFA 

H)| juD g(WDB) = (|g(WDB)) (3) 

WVB WVB 

and Q is bisimulation invariant or respecting informational equivalence. Here 
WDB is the class of all WDBs (i.e. finite labelled or unlabelled graphs) with a 
distinguished URL (vertex) u in each, to which (]-) is actually applied. 

The expressive power of this language and its versions was completely char- 
acterised in terms of PRIME- (both for HF and HFA) and (N/D)LOGSPACE- 
(for HF) computability over graphs via (3) [33,34,24,25,23,22]. It is because of 
flexibility, naturalness and reasonable level of abstractness of our set-theoretic 
approach to WDB (which seemingly nobody else used in the full power) such 
expressibility results where possible. Here it is probably suitable to mention, for 
the contrast, a quotation from [8], p. 14: “It should be noted that basic questions 
of expressive power for semistructured database query languages are still open” . 

^ HF and HFA below may be considered in two versions: (i) labelled one when a 
set in the universe consists of labelled elements (which can be also such sets, or, 
may be, urelements or atoms), and (ii) pure, atoms and labels-free version — the 
ordinary pure sets of sets of sets, etc., the empty set being the simplest object. For 
simplicity, A-language and calculus of agents presented in Sect. 3 and 5, respectively, 
are devoted to the pure case. Labelled case would seemingly add nothing essential 
to our agents approach. Anyway, it is better to start with the simplest case. 
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A preliminary experimental implementation of a version of A [38] has been 
developed (when the author worked) in the Program Systems Institute of Russian 
Academy of Sciences (in Pereslavl-Zalessky) as a query language for the “real” 
WWW which is based on the steps of browsing, searching, etc. described above. 

3 Hyper-Set /1-Language for Querying WDB 
3.1 Basic .^-Language for the Pure HF or HFA^ 

Definition 3.1. Define inductively A*-formulas and A*-terms by the clauses 

(Z\*-terms) ::= (variables) | 0 | {a, 6} | (^ a | {t{x) \ x a & ^(x)} 

(Z\*-formulas) ::= a = b \ aG^*^b \ (p k, ip \ -xp | yxG^*^ap{x) 

where tp and ip are any Z\*-formulas, a, b and t are any Z\*-terms and a; is a 
variable not free in a. The parentheses around * in mean that there are two 
versions of the membership relation: G and its non-reflexive transitive closure 
G*. We write A when G* is not used at all. The sub-language A corresponds to 
the basic [17] or rudimentary [21] set-theoretic operations. 

From the database’s point of view, (labelled version of) the language A 
is analogous to relational calculus, however it is devoted to arbitrary sets 
of sets of sets, etc. rather than to relations — also sets of a specific kind. 

The main idea is that Z\-formulas involve only bounded quantification 
Wx G*-*^ a and 3x G^*^ a^-kx G^*^ a-' with the evident meaning. All other 
constructs of A are also in a sense “bounded”. But, for example, the unre- 
stricted power-set operation V{x) ^ {y ■ y Q x} is considered as intuitively “un- 
bounded”, “impredicative” , computationally intractable, and therefore it is not 
intended to be taken as natural extension of A. 

For simplicity, as common, we shall use set variables, Z\*-terms and formulas 
both as syntactic objects and as denotations of their values in HF (HFA). For 
example, Z\-separation {x G a : p{x)} ior p G A gives ‘the set of all x in the set a 
for which p{x) holds’ and is a special case of the construct {t(a;) : x G a k p{x)} 
= ‘the set of all values of t{x) such that . . . ’. Also x G {a,b} iS x = a or x = b, 
x G (J a iff 3z G a(x G z) and G* is a transitive closure of the membership 
relation G on HF (HFA), i.e. x G* y iS x G Xi G X2 G ... G x„ G y for some 
n > 0 and xi, ... ,Xn in HF (HFA). In particular, define in A* the transitive 
closure of a set y as TC(y) ^ {y} U {a; : cc G* y}. 

Any Z\-term t{x) evidently defines a set-theoretic operation \x.t{x) : 
HFA” — >• HFA. For example, let u U ^ (J {m, u}, u fl u ^ {x G m : x G u}, 
u\v^ {x G u : X ^ v}, {u} ^ {u,u}, {^1,^2, . . . ,Uk} ^ {ui}U{u2}U. . .Ujufe}. 
Ordered pairs and related concepts are defined in A as (u,v) {{m}, {w,u}}, 

or (in the labelled case), more naturally from a practical point of view, as 
{Fst : u, Snd : u} for some two special labels (attributes) Fst and Snd, etc. 

® See [34] for generalisation of A for the case of HF and HFA with nrelements (atoms) 
and labels (attributes). 
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3.2 Extensions of A* 

There are important extensions of Z\*-language corresponding to PTIME or 
(N/D)LOGSPACE computability over HFA, resp., HF, as we mentioned in 
Sect. 2. Due to lack of space, we will consider only those giving rise to PTIME. 

Decoration (Aczel, [3]) 

DiHFA^HFA, D((5,u)) = flu^g 

with g € HFA any graph (set of ordered pairs in set-theoretic sense). The 
decoration operation D embodies Aczel’s Anti-Foundation Axiom. 
Collapsing (Mostowski, [6]) 

C : HF ^ HF 

is partial case of D : HFA — ^ HFA when g is any well-founded, i.e. acyclic 
graph (in the finite case considered). 

Recursive Z\-Separation term construct Rec: 

the-least p.[p = {x & a : (p{x,p)}\ 

for ip £ A positive (and with an additional requirement) on set variable p. 

4 Using Agents for Concurrent Querying WDB 

What is new in the present approach. The main problem with implement- 
ing the set-theoretic language A is that (potentially) a significant amount of 
browsing may be required during query evaluation. In the real Internet the re- 
sult of each mouse click on a hyper-link (downloading a page from remote site) is 
delayed by several seconds at best and the whole time of querying may take hours 
(despite all other pure computation steps being much faster). Therefore, some 
radical innovation in the implementation is necessary to overcome the problem 
of multiple browsing via the Internet (in a non-efficient, sequential manner). 

A well-known technique, used by most search engines such as Alta Vista, is 
that of creating (and permanently renewing) an index file of the WWW to which 
queries are addressed and some parts of which may be actually rather old. 

The approach described here is aimed at “goal-directed” querying the real 
Web, as it is at the current moment, where reorganising the data (not only 
searching) is an additional and crucial feature of the query language A. 

As a reasonable solution, we suggest using Dynamic Agent Creation. The 
set-theoretic language A appears very appropriate for this goal. 



Agents as A-terms. Each agent, i.e. essentially a Z\-term (= a query q = q{u) 
written in Z\-language) having an additional feature of an active behaviour, when 
starting querying from “his” local site s, may also send (via the Internet) to re- 
mote sites si, S 2 , . . . some appropriate sub-terms pi,p 2 , ■ ■ ■ which, as agents, will 




Using Agents for Concnrrent Querying of Web-Like Databases 385 



work analogously on these remote sites, i.e., if necessary, will send new descen- 
dant agents, etc. Eventually, the main agent will collect all the data obtained 
from this process. Potentially, the whole Internet would concurrently participate 
in the distributed evaluation of the given query. We expect that this will essen- 
tially accelerate querying. One of medium-term goals is to establish the truth of 
this expectation in a theoretical framework. Another goal is producing an exper- 
imental agent based implementation of the language A to check practically this 
expectation and to get more experience for further developing this approach. 

A Typical Example. To calculate the set-theoretic Z\-term (in unlabelled case) 

q = {p{v) \ v G a}, 

i.e. the “set of all p{v) such that v is in a”, this term, as an “agent”, sends many 
descendant agents/sub-terms p{v) for all (URLs) v contained on the page a to the 
various, probably remote, sites Site(w) of the WWW to which all these (URLs) 
V refer. When each agent p{v) finishes “his” computation (possibly with the 
help of their descendant agents), “he” will send the result to the “main agent” 
q, “who” will appropriately collect all the results together as a new (URL — 
the value of q — and corresponding html file of a) Web-page containing all the 
computed URLs p{v) for all v G a. Each agent q, p{v), for all v G a, etc. will 
resolve “his” own task, which may be probably not so difficult and burdensome 
for the site resources where the agent works, since “his” descendant agents will 
do the rest of the job possibly on other sites. If, by some reason, the “permission 
is denied” to send a descendant agent to a remote site, the parent agent will 
also take corresponding part of the job and will do it “himself” from “his” local 
site — by browsing, searching, etc. 

The further and most crucial goal of the described work therefore consists 
in formalising the ideas above. It may be done in the form of a specially elabo- 
rated (or suitably adapted for the query language A considered here) calculus of 
agents which describes as descendant agents are creating, moving around, doing 
their job, communicating their result to the “senior” agents by which they were 
created, until the result of the initial query is obtained. In particular, this will 
give agent based graph transformer operational semantics for the language A. 
Some appropriate version of the corresponding agent calculus (for a partial case 
covering the above example) will be presented in Sect. 5. We realize that this is 
probably not the unique possible version. Cf. discussion below. 

Correctness of this semantics with respect to natural (hyper) set-theoretical 
semantics must be proved. It should be shown rigorously that the time complex- 
ity of this approach with agents is really better than that without agents (i.e. 
essentially with only one main agent which creates no sub-agents and makes all 
“his” job of browsing, searching and creating pages alone). In particular, it is 
necessary to formulate and develop a reasonable approach to time and space 
complexity for agent based querying (cf. the next paragraph) and then to esti- 
mate and compare time and space complexity of queries either when agents are 
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used or not. In the ideal, the resulting agent calculus should be capable of being 
implemented as a working query system to a WDB, say, to the WWW. 

Note that an appropriate abstraction from querying of the WWW should 
be found. For example, in reality, each step of browsing requires some physical, 
actually unpredictable time. For simplicity it may be taken that each step of 
browsing or exchanging information between agents takes one unit of time and 
all other computation steps (of searching some information trough Web-pages 
and composing new ones) cost nothing (in comparison with the browsing). Also 
when several agents are sent to the same Web-site for their work their activity 
may be considered either as sequential or in an interleaving manner according 
to communication with other agents. Space complexity also may be considered 
in a simplified version, e.g. as the maximum number of agents working simulta- 
neously. The simultaneity concept should be also defined (approximated) appro- 
priately as the run of time in the model may not correspond to the real one, as 
we noted above. On the other hand, how much of memory resource each agent 
needs on its site (server) could additionally be taken into account. All of this 
seems has no canonical or simple, most elegant theoretical solution. 



Some related work (i) on communication and concurrency by R. Milner and 
P. Aczel, [28,4,5], (ii) on mobile agents (ambients) by R. Milner et al. [29], 
L. Cardelli [8], C. Fournet et al. [16], (iii) on logical specification of agents’ be- 
haviour by M. Fisher and M. Wooldridge [15], (iv) on distributive querying by 
D. Suciu [40,41] and A. Sahuguet et al. [31], (v) on corresponding application to 
agents of Y. Gurevich’s Abstract State Machines [13], (vi) on Mobile Maude by 
J. Meseguer et al. [12], (vii) on Nomadic Piet [30], (viii) on a project LOGIC 
Programming for the World-Wide WEB by A. Davison et al. [11] and probably 
many others could be useful in our specific set-theoretic context either ideologi- 
cally, or by direct using corresponding formalisms or their analogues. 

However, in our very concrete situation it seems reasonable to present a 
calculus of agents from the principles which the query language A almost imme- 
diately “dictates” according to its natural and clear semantics, postponing for a 
while comparison with other formalisms and ideas, because here we will present 
only rather preliminary, even not completely rigorous version of a calculus. 



Further perspectives from the practical point of view. It is clear, that the 
whole approach depends on giving permissions by various Web sites for agents 
to work there. For a WDB on a local net or on an Intranet this problem can be 
resolved by an agreement with the administrator of the net. However, for the case 
of the global Internet the whole Internet community should agree on a general 
standard for such permissions with an appropriate guarantee of no danger from 
the “arriving” agents. Of course this may depend on whether this framework will 
be sufficiently successful for local nets, as well as on the current state of affairs 
concerning programming of distributed computation in the Internet. 
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5 A Fragment of a Calculus of Agents for Computing 
/1-Queries (Preliminary Semiformal Version) 

According to our informal description in the previous section, each Web-site s 
(server, or even any computer with a Web-browser)^ may contain agents/queries 
(j??, or <7 = ?? working on the site s (where q, with some exceptions, is a Z\- 
term or Z\- formula; the general form of an agent /query is presented in (4)). All 
queries on a site s constitute a queue q according to which (from left to right) 
they should be evaluated. We consider the expression sq as, & current state of a 
site s w.r.t. (the state of) its queries in q. 

The double question mark “7?” means that the query/agent is waiting for 
the server s to start (or allow) executing it, while a single question mark “?” 
corresponds to an agent q which has already started to work, but at present is 
awaiting results from its subqueries (descendant agents) which have been sent 
to other sites. Also, we use single “?” for so-called “passive” queries which are 
only waiting for results from “active queries” (cf. below). 

Thus, the sequence q consists of active agents /queries (syntactically more 
complicated than just “q = ??”) formally written in round brackets as: 

{qi = Siidi), z=l,...,m. (4) 

Here “— >■ Siid/ is read as “send the result of the query to the site Si by the 
address id/ . Expressions like id of our agents metalanguage are query identities 
of various “passive” subqueries (to be considered below — they are parts of e- 
expressions of other, actually parent agents/queries also of the form (4)). These 
identities are needed to distinguish occurrences of “passive” subqueries and also 
to serve as their addresses in the corresponding queues (the current implicit 
queue in the site Si, in the case of (4)). All query identities constitute a set Id of 
finite strings consisting of some standard computer keyboard symbols starting 
with, say, ^ and containing no more 

Some special identities written as ^browser-of- < user > are reserved as 
special, exceptional cases, used for queries of the form 

{qi = ??—>■ s^/fibrowser-of- < user >) 

in the site-queue sq initiated by some (human) user /agent working on another 
site s' (his PC). This query will be started for execution on the site s (according 
to our formal calculus of agents to be partially described below). Let us assume 
that some URL Ui will be obtained by evaluating (probably in many steps) 
the query “qi = ??”, giving rise to the result “qi = u/ . Then, the remaining 
part “— >■ s'#browser-of- < user >” means that the resulting Page(rti) should 
be opened in a new window of a browser on the site s' with some additional 
special subwindow in the browser where the answer “QUERY RESULT OF <user> 

^ Everything is still considered in a very abstract way; our Web or Internet terminology 
is used mainly to provide a general intuition rather than a complete or very precise 
correspondence to standard concepts. 
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IS: Qi = Mj” to the query is explicitly written for the user’s convenience to 
understand why this (perhaps suddenly appearing because of a possible time 
delay) browser window and its content Page(ui) arose. 

Let us define in general what the expression ti in (4) may be: 

— double question mark or 

— just some resulting Ui € URL, if gi is Z\-term (a normal query), or a resulting 
boolean value true or false, if Qi is Z\-formula (a boolean query), or 

— starting with a single question mark “?” and possibly with a URL, a sequence 
of auxiliary passive queries or corresponding answers in square brackets 

[idr : r = ?] or [idr : r = ufi\, or [id^ : r = Ur], (5) 

with Ur G URL, Ur a finite set of URLs or some simple expressions consisting 
of URLs (in the last two cases, the “id :” will usually be omitted); these 
passive queries or answers are needed to calculate the answer to the main 
query (4) which is of the form 

{q, = Siidi) or {qi = ?url[. ^ Siid,); (6) 

moreover, all query identities idr should be different in passive queries of 
the whole queue q (to serve as unique addresses of these passive queries for 
sending the answers from other sites). 

Here a single “?” at the beginning of Ci indicates that the result of qi in (4) or (6) 
is still unknown. Even if we have some url in (6), the content of the Page(Mr/) 
may be not completed yet. To get the result of qi in (6) some further actions of 
this agent may be required even if all passive subqueries are already answered 
and replaced by the results of the form [r = Ur] or [r = Ur]- 

As the server s may be “busy” with its own work or evaluating queries from 
the queue q, it is indeterminate when it will execute the first “waiting” query gfil 
or qi? (with queries for all j < i having already some final answers Uj G URL or a 
boolean value true or false, for boolean queries, or waiting the results from their 
descendant subagents which already have been sent to some sites by the agent 
qj with the help of the server s). Therefore we should have nondeterministic, 
asynchronous and concurrently applied reduction rules for the extended sites sq. 

Note that all Z\-queries qi should be closed terms or formulas with free vari- 
ables substituted by some url s (the addresses of WDB-pages which simultane- 
ously denote corresponding sets (]url\) according to (1) or (2) — in our present 
“pure” case). However, qi may be also a specially created agent which is not 
formally a Z\-term. 

Some qi may be just a constant u G URL. This query does not require eval- 
uation. As a URL, it is the final result of evaluation of the query. Therefore let 
us introduce the trivial rule for such atomic qp. 

sq{u = ??—>■ s'id')q' i — >■ sq{u = w — >■ s'id')q'. (7) 

The following double structural rule {inseparable into two independent 
parts; same for other “multiple rules” below presented in curly brackets), for the 
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sequential replacement of queues in two sites, shows what happens after a query 
agent qi has received an answer Ui (say, as in the trivial case of (7)): 

f sq{qi = Ui^ Siidi)q' i — sqq' , 

\ s^q” I — Si{ui idi)q” 

(if s = Si then it is naturally assumed that q” = qq' should hold) where the 
substitution operator {ui — >■ idi) means that the (unique) subquery [idi : ... = 
?] (of some parent agent) with the same idi should be found in an e part of 
(<7 = e — >■ . . .) occurring in q" and corresponding “?” should be replaced by 
Ui with idi possibly omitted as already used and unnecessary anymore, giving 
result [• • • = Ui] in e in the place of the passive query [idi occurrence. 




5.1 Rules for the Query “{p(f) | u 6 a} =??” 

The following three rules are devoted to the query “{p(v) \ v S a}??”, informally 
considered in the previous section. 

The first rule postpones the main query in favour of (a = ??—>■ s ida) sent 
to the same site s, last in the queue: 

sq{{p{v) I u G a} = ??—>■. . .)q i — >■ 

sq{{p{v) I u G a} = 7[ida : a = ?]-)>. . .)q'{a = ??-)> sida) 

As discussed above, the part “— >■ szda” shows where the result should be sent; 
here, to the same site and queue to the passive query (in the main query) labelled 
by ida- Note, that expressions [ida : a = 7] and (a = ?? — >■ sida) play different 
roles in the queue (passive and active, respectively). When the latter will be 
resolved, with some result Ua G URL, it can be annihilated, as in (8), after the 
“?” in the former expression will be replaced by the result Ua obtained. 

The second, multiple rule has additionally a premise condition^ assuming 
that on the site s the query/agent {{p(v) | u G a} = ?[a = Ua] —>■...) (already 
“knowing” that Ua is the value of a) first inspects the content of the Page(rta) 
(say, with the help of a browser on the site s). Then, depending on the result in 
the premise, the following multiple rules under the horizontal line are performed: 

Page(Mg) = {mi, . . .,Uk} 

{ sq{{p{v) [ V G a} = 7[a = Ua] ^ . . .)q' ' — 
sq{{p{v) I u G a} = 7[a = Ua][idi : p(ui) =?]... [idk ■ p{uk) = ?]-)>.. .)q' , 

Site(ui)gi I — > Site{ui)qi{p{ui) = 77 ^ sidi), i = l,...,k. 

Again, the main query is postponed until new descendant agents of the form 
{p{ui) = ??—>■ sidi) (depending on the result Ua of the query “a = ??”, or, more 
precisely, on the content of Page(ug)) are created and sent to the sites Site(wi) 
(with their current queues qi) to work there and to calculate values of p{ui). 

® We could use instead an if-then construct or just composition of some actions. 
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Finally, the following rule allows the complete evaluation of the query 
“{p{v) I u G a} = ??”: 

Page(Mg) = {ui , . . .,Uk}, new Page(M) = {u [, . . 

sq{{p{v) I u G a} = ?[a = Ua][p{ui) = u'l] . . . [p{uk) = u',^] ■ ■ -)q' ' — 

sq{{p{v) I u G a} = u — . .)q' 

where u is a new URL on the site s ( Site (n) = s) such that Page (u) = {u[, . . . 

It is assumed that the current agent, with all passive queries answered, 

{{p{v) I u G a} = ?[a = Ua][p{ui) = u[] . . . [p{uk) = n'fc] 

will create this new page on its site s which will automatically receive a URL 
u (depending on the directory where corresponding html file with this page will 
be saved and, of course, on the name of this file — as usual for URLs). 

5.2 Rules for the Transitive Closure TC 

The rules for calculating TC(a) are based on the following simple ideas. Starting 
from the calculation of URL Ua = a, numerous identical copies of a special 
agent TC' are sent step-by-step (first by TC, and then by descendant TC's) to 
(the sites of) descendants v of the vertex Ua in the given graph of the WDB. 
Each copy TC'(u) gathers URLs immediately accessible from v and sends them, 
with the information how they were obtained, to the main agent TC(a) which 
collects all of this information in a newly created file Page(u) with a URL u. 
When all URLs reachable from Ua are collected in Page(rt), this parallel process 
is considered finished, and gives the result u. 

The first rule is as in the previous subsection: 

sg(TC(a) = ?? ^ . . .)g' ^ 

sg(TC(a) = l[ida : a = ?]—>■. . ■)q\a = ??—>■ sida) 

The secoud, multiple rule has an additional premise condition: 

Page(rtg) = {mi, . . . ,Uk\ new Page(u) = {ug -)> rti, . . . , Ug Uk} 

( sg(TC(a) = ?[a = Wg] . .)q' i — 

J sq{TC{a) = 7u[a = u^] [idrc : TC'( ) = ?] ^ . . .)q' 

{ Site{ui)qi I — )> Site(Mi)g*(TC'(ui) =??-)> sidrc), i = I,. ■■ ,k. 

Again, the main query is postponed until new descendant agents of the form 
(TC'(ui) =??—>■ sidi) (depending on the result Ug of the query “a = ??”) 
are sent to the sites Site(ui) (with their current queues iji) to work there and 
to calculate values of TC'(ui). Here TC'( ) is a new agent generated by TC. 
URLs Ui serve as parameters for TC'. We also use TC'( ) without parameters 
in the corresponding passive queries. Further, u is a new URL on the site s 
(Site(u) = s) such that (at the beginning of calculating of TC(a)) Page(w) = 
{ua — >■ Page(wg)} = {ua ui, . . . ,Ua Uk} (a set of arrows between URLs). 
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We see that the format of e expressions is slightly extended in comparison 
with the previous subsection. However here we seemingly have an answer u 
to the question “TC(a) = ??”, the question mark before u indicates that this 
answer is only a partial one. More precisely, it is partial only in the content of 
the corresponding Page(u) ( = {ua u\, ... ,Ua — >■ Uk} at the first moment). It 
should be extended with the help of descendant agents of the form TC^(u). 

Moreover, we need to consider, more generally, that the answer to any 
subquery [TC'(u) = ?] (first, v = Ui from the above rule) is the set of 
arrows between URLs U = {w — Page(u)} = {u — >■ Vi, . . . , w — u„}, where 
Page(u) = {ui, . . . , Vn} (we let 17 = {u — >■ } if Page(w) = 0, i.e. v has no children) 
whereas in the previous subsection it was assumed that only some URLs may 
be query answers. 

The third, also multiple rule describes the behaviour of the agent TC^ 
which (i) creates a set of arrows v ^ Vi outgoing from the URL v under consid- 
eration (as described above), and (ii) propagates its copy to sites Site(ui). From 
each site where (a copy of) TC' is working, it sends the results to the same place 
sidTC- 

Page(v) = {vi, ...,Vn} U = {v ^ {ui, . . . ,u„}} 



Site(u) g(TC^(u) = ??—>■ sid,Tc)Q ' ' — ^ 

Site(w) g(TC^(u) = [/—>■ sid,Tc)Q' 

Site(uj)ft I — )> Site(ui)gj(TC'(uj) = ??-;> sidrc), i=l,...,n. j 

The rule continuing partial evalnation of the query “TC(a) = ??” (ex- 
tending the content of Page(u)): 

Page(u) := Page(u) U U 

s q{TC{a) = 7u[a = Ua] [idrc ■ TC'( ) = [/]-)>.. .)q' i — 
sq{TC{a) = ?u[a = Ua][tdTc : TC'( ) = ?] ^ . . .)q' 

Here u is (intended to be) the URL created above on the site s (Site(w) = s) 
such that Page(u) is the union of the old version and the set of arrows, say, 
U = Ui = {ui — >■ Page(ui)}. The passive query [zcItc ^ TC'( ) = ?] appears again 
to wait some new U from other TCqu). 

Finally, we present a rule to complete the calculation of TC(a): 

Assuming all participating URLs in Page(w) occur as the left ends of arrows, 
the optional action: omit in this page all arrows 
and duplication of all remaining URLs 
sg(TC(a) = 7u[a = Ua][*c?TC : TC^( ) = ?]—>■.. .)q' i — > s q(TC{a)=u — 1- . . .)q' 

The premise condition guarantees that Page(u) is completed as required, giv- 
ing the whole transitive closure of a (or Ua), possibly with some arrows mak- 
ing Page(u) a graph. In the latter case, given any a and b, we could use the 
corresponding versions of TC(a) and TC(6) to calculate the bisimulation rela- 
tion between corresponding graphs and then, if needed, to evaluate also queries 
“(a = 6)??” and “(aG 6)??”. 
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We postpone considering rules, their correctness and conditions and possible 
exceptions of applicability for the above and other constructs of the Z\-language 
until a more advanced version of this paper will be prepared (with a bigger 
volume allowed). Even in this form they demonstrate how the mobile and prop- 
agating agents can work over a (potentially World-Wide) distributed Web-like 
hyper-set database in a concurrent, asynchronous and distributed manner to 
evaluate set-theoretically described queries. After developing a full version of 
the calculus of “Z\-agents” both theoretical and practical (directed towards im- 
plementation) investigations can be carried out independently. 

5.3 What Makes Agents Active, or How Could They Be 
Implemented? 

Of course, agents, as they are described above, are only syntactic expressions. To 
make them active and really mobile, concurrent and working distributively, we 
need a unique program Distributed Query Evaluator DQE installed (desirably) 
on each WDB (or WWW) site which will fulfil all the necessary rules of manip- 
ulating queues (and agents in them). Of course, it should be sufficiently flexible 
to work even if some sites do not have installed DQE or do not currently allow 
our agents. Also it should be able to redirect some agents to other neighbour or 
“friendly” sites if the queue on the current site is too long, etc. Only in this case 
will the whole enterprise of making querying in A considerably more efficient 
according to the ideas presented in this paper be successful. It is really a diffi- 
cult problem to make such a program which the whole Internet community and 
computer and software companies will adopt like well-known browsers (Internet 
Explorer or Netscape). Anyway, any new step in such a direction (theoretical, 
experimental, practical) to make the Internet a big commnnity of com- 
puters helping one another seems a reasonable (much more general than our 
present) task. 

6 Conclusion 

The starting point for this research was a mostly theoretical one related to de- 
scriptive complexity theory and to extending its methods to relational, nested, 
complex and Web-like distributed databases grounded on (hyper) set theory. 
Our present work is also theoretical, but it is directed towards the problem of 
developing a necessary radical step for more efficient implementation. Consid- 
ering dynamically created agents in full generality, working and communicating 
concurrently, asynchronously and distributively over the Internet is not the im- 
mediate goal of research here. We rather represent a machinery for achieving 
the efficiency of querying in the present (hyper)set approach. As a result, this 
work may be of direct benefit to research communities on semi-structured and 
distributed databases and on multi-agent systems. It also has the potential of 
longer term benefit to the Internet community. More concretely, it may lead to 
better understanding of the basic principles of efficient querying of WDB and to 
an experimental prototype of such a query system. 
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Abstract. A general semantics-based framework for the analysis of logic 
programs with delay declarations is presented. The framework incor- 
porates well known refinement techniques based on reexecution. The 
concrete and abstract semantics express both deadlock information and 
qualified answers. 



1 Introduction 

In order to get more efficiency, users of current logic programming environments, 
like Sictus-Prolog Prolog-Ill, CHIP, SEPIA, etc., are not forced to use 
the classical Prolog left-to-right scheduling rule. Dynamic scheduling can be 
applied instead where atom calls are delayed until their arguments are sufficiently 
instantiated, and procedures are augmented with delay declarations. 

The analysis of logic programs with dynamic scheduling was first investigated 
by Marriott et al. in [I18lll| . A more general (denotational) semantics of this class 
of programs, extended to the general case of CLP, has been presented by Falaschi 
et al. in while verification and termination issues have been investigated by 
Apt and Luitjes in [2] and by Marchiori and Teusink in respectively. 

In this paper we discuss an alternative, strictly operational, approach to 
the definition of concrete and abstract semantics for logic programs with delay 
declarations. 

The main intuitions behind our proposal can be summarized as follows: 

- to define in a uniform way concrete, collecting, and abstract semantics, in 
the spirit of HD: this allows us to easily derive correctness proofs of the 
whole analyses; 

- to define the analysis as an extension of the framework depicted in m- 
this allows us to reuse existing code for program analysis, with minimal 
additional effort; 

- to explicitly derive deadlock information (possible deadlock and deadlock 
freeness) producing, as a result of the analysis, an approximation of concrete 
qualified answers; 
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- to apply the reexecution technique developed in [15j : if during the execution 
of an atom a a deadlock occurs, then a is allowed to be reexecuted at a 
subsequent step. 

The main difference between our approach and the ones already presented 
in the literature is that we are mainly focussed on analysis issues, in particular 
on deadlock and no-deadlock analysis. This motivates the choice of a strictly 
operational approach, where deadlock information is explicitly maintained. 

In this paper we present an extension of the specification of the GAIA ab- 
stract interpreter [14] to deal with dynamic scheduling. We design both a con- 
crete and an abstract semantics, as well as a a generic algorithm that computes 
a fixpoint of the abstract semantics. This is done following the classical abstract 
interpretation methodology. 

The main idea is partitioning literals of a goal g into three sets: literals 
which are delayed, literals which are not delayed and have not been executed 
yet, and literals which are allowed to be reexecuted as they are not delayed but 
have already been executed before and fallen into deadlock. This partitioning 
dramatically simplifies both concrete and abstract semantics with respect to the 
approach depicted in j^, where a preliminary version of this work was presented. 

Our approach uses the reexecution technique which exploits the well known 
property of logic programming that a goal may be reexecuted arbitrarily often 
without affecting the semantics of the program. This property has been pointed 
out since 1987 by Bruynooghe m and subsequently used in abstract interpreta- 
tion to improve the precision of the analysis |15j . In this framework, reexecution 
allows to improve the accuracy of deadlock analysis, and its application may be 
tuned according to computational constraints. 

The rest of the paper is organized as follows. In the next section we recall some 
basic notions about logic programs with delay declarations. Section E] depicts 
the concrete operational semantics which serves as a basis for the new abstract 
semantics introduced in Section 01 Correctness of our generic fixpoint algorithm 
is discussed. Section [^ concludes the paper. 

2 Logic Programs with Delay Declarations 

Logic programs with delay declarations consist of two parts: a logic program and 
a set of delay declarations, one for each of its predicate symbols. 

A delay declaration associated for an n-ary predicate symbol p has the form 

DELAY p{xi,...,Xn) UNTIL Cond{x\, . . . ,Xn) 

where Cond{xi, . . . , a;„) is a formula in some assertion language. We are not con- 
cerned here with the syntax of this language since it is irrelevant for our purposes. 
The meaning of such a delay declaration is that an atom p(ti, . . . ,tn) can be se- 
lected in a query only if the condition Cond{ti, . . . ,tn) is satisfied. In this case 
we say that the atom p(ti , . . . , satisfies its delay declaration. 

A derivation of a program augmented with delay declarations succeeds if it 
ends with the empty goal; while it deadlocks if it ends with a non-empty goal 
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no atom of which satisfies its delay declaration. Both successful and deadlocked 
derivations compute qualified answers, i.e., pairs of the form {9,d) where d is 
the last goal (that is a possibly empty sequence of delayed atoms) and 9 is 
the substitution obtained by concatenating the computed mgu’s from the initial 
goal. Notice that, if {9,d) is a qualified answer for a successful derivation then 
d is the empty goal and 9 restricted to the variables of the initial goal is the 
corresponding computed answer substitution. We denote by qansp{g) the set of 
qualified answers for a goal g and a program P. 

We restrict our attention to delay declarations which are elosed under instan- 
tiation, i.e., if an atom satisfies its delay declaration then also all its instances do. 
Notice that this is the choice of most of the logic programming systems dealing 
with delay declarations such as IC-Prolog, NU-Prolog, Prolog-II, Sicstus-Prolog, 
Prolog-Ill, CHIP, Prolog M, SEPIA, etc. 

The following example illustrates the use of delay declarations in logic pro- 
gramming. 

Example 1. Consider the program PERMUTE discussed by Naish in m- 

y, perm(Xs,Ys) •«— Ys is a permutation of the list Xs 
perm(Xs,Ys) •«— Xs= [], Ys= []. 

perm(Xs,Ys) •«— Xs = [XlXls], delete(X,Ys,Zs) , perm(Xls , Zs) . 

y, delete(X,Ys,Zs) Zs is the list obtained by removing X from the list Ys 
delete (X,Ys,Zs) C- Ys = [X I Zs] . 

delete(X,Ys,Zs) Ys = [XllYls], Zs = [XlIZls], delete(X,Yls,Zls) . 

Clearly, the relation declaratively given by perm is symmetric. Unfortunately, 
the behavior of the program with Prolog (using the leftmost selection rule) is 
not. In fact, given the query 



Qi := -i— perm(Xs, [a, b]). 

Prolog will correctly backtrack through the answers Xs = [a, b] and Xs = [b, a]. 
However, for the query 



Q 2 := ^ perm([a, b],Xs). 

Prolog will first return the answer Xs = [a, b] and on subsequent backtracking 
will fall into an infinite derivation without returning answers anymore. 

For languages with delay declarations the program PERMUTE behaves sym- 
metrically. In particular, if we consider the delay declarations: 

DELAY perm(Xs,_) UNTIL nonvar(Xs) . 

DELAY delete Zs) UNTIL nonvar(Zs) . 

the query Q 2 above does not fall into a deadlock. ■ 

Under the assumption that delay declarations are closed under instantiation, 
the following result, which is a variant of Theorem 4 in Yelick and Zachary m. 
holds. 
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P £ Programs 

pr £ Procedures 

c £ Clauses 

h £ ClauseHeads 

g £ Literals equences 

I £ Literals 

a £ Atoms 

b £ Built-ins 

p £ ProcedureNames 

f £ Functors 

Xi £ ProgramVariables 



P ::= pr^,...,pr^ (n > 0) 
pr :■.= Cl, ... ,Cn (n > 0) 
c :-.= h:-g. 

h p(xi, ..., Xn) (n > 0) 
g ::= h,...,ln [n> 0) 

I ::= a \ b 

a ::= p{xi^,...,XiJ (n>0) 
b :■.= Xi = Xj \ Xi^ = f{xi^,. . .,XiJ 



Fig. 1. Abstract syntax of normalized programs 



Theorem 1. Let P be a program augmented with delay deelarations, g be a goal 
and g' be a permutation of g. Then qansp(g) and qansp(g') are equals modulo 
the ordering of delayed atoms. 

It follows that both successful and deadlocked derivations are “independent” 
from the choice of the selection rule. Moreover, Theorem [T] allows us to treat 
goals as multisets instead of sequences of atoms. 

3 The Concrete Operational Semantics 

In this section we describe a concrete operational semantics for pure Prolog 
augmented with delay declarations. The concrete semantics is the link between 
the standard semantics of the language and the abstract one. We assume a 
preliminary knowledge of logic programming (see, |1I16| 1. 



3.1 Programs and Substitutions 

Programs are assumed to be normalized according to the syntax given in Fig. [T] 
The variables occurring in a literal are distinct; distinct procedures have distinct 
names; all clauses of a procedure have exactly the same head; if a clause uses m 
different program variables, these variables are xi, . . . , Xm- If 5 := ai, . . . , a„ we 
denote hy g\ui the goal g' := oi, . . . , a^-i, a^+i, . . . , a„. 

We assume the existence of two disjoint and infinite sets of variables: program 
variables, which are ordered and denoted hy x\, X 2 , . . . , Xi, . . . , and standard 
variables which are denoted by letters y and z (possibly subscripted) . Programs 
are built using program variables only. 

A program substitution is a set {xi^^/ti, . . . ,Xi^/tn}, where . . . ,Xi^ are 
distinct program variables and t\, ... ,tn are terms (built with standard variables 
only). Program substitutions are not substitutions in the usual sense; they are 
best understood as a form of program store which expresses the state of the com- 
putation at a given program point. It is meaningless to compose them as usual 
substitutions. The domain of a program substitution 9 = 
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denoted by dom{0), is the set of program variables {xi^^ . . . ,Xi^}. The applica- 
tion Xi9 of a program substitution 0 to a program variable Xi is defined only 
if Xi G dom{9): it denotes the term bound to Xi in 9. Let 19 be a finite set of 
program variables. We denote by PS jj the set of program substitutions whose 
domain is D. 

3.2 Concrete Behaviors 

The notion of concrete behavior provides a mathematical model for the in- 
put/output behavior of programs. To simplify the presentation, we do not pa- 
rameterize the semantics with respect to programs. Instead, we assume given a 
fixed underlying program P augmented with delay declarations. 

We define a concrete behavior as a relation from input states to output states 
as defined below. The input states have the form 

- {9,p), where p is the name of a procedure and 0 is a program substitution also 

called activation substitution. Moreover, 9 G where xi , ... ,Xn 

are the variables occurring in the head of every clause of p. 

The output states have the form 

- (0', k), where 9' G PS k is a deadlock state, i.e., it is an element 
from the set {<5, where 5 stands for definite deadlock, while v stands for no 
deadlock. In case of no deadlock, 9' restricted to the variables {x\, . . . ,cc„} 
is a computed answer substitution (the one corresponding to a successful 
derivation), while in case of deadlock, 9' is the substitution part of a qualified 
answer to p and coincides with a partial answer substitution for it. 

We use the relation symbol i — >■ to represent concrete behaviors, i.e., we write 
{9,p) I — > {9' , k): this notation emphasizes the similarities between this concrete 
semantics and the structural operational semantics for logic programs defined 
in m Concrete behaviors are intended to model successful and deadlocked 
derivations of atomic queries. 

3.3 Concrete Semantic Rules 

The concrete semantics of an underlying program P with delay declarations is 
the least fixpoint of a continuous transformation on the set of concrete behav- 
iors. This transformation is defined in terms of semantic rules that naturally 
extend concrete behaviors in order to deal with clauses and goals. In particular, 
a concrete behavior is extended through intermediate states of the form {9, c) 
and {9, g_d, g.e, gjr), where c is a clause and g.d, g.e, gjr is a partition of a goal 
g such that: g.d contains all literals in g which are delayed, g_e contains all lit- 
erals in g which are not delayed and have not been executed yet, gjr contains 
all literals in g which are allowed to be reexecuted, i.e., all literals that are not 
delayed and have already been executed but fallen into a deadlock. 

- Each pair (0, c), where c is a clause, 0 G PS [xi,...,xn} and xi, . . . ,x„ are the 
variables occurring in the head of c, is related to an output state (9',k), 
where 0' G PS and k G {<5, v} is a deadlock state; 
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- Each tuple {0,g-d,g-e,gjr), where 9 € PS and are the 

variables occurring in (g_d, g^e, g^r), is related to an output state {0\k), 
where 9' £ PS and k £ {5, v} is a deadlock state. 

We briefly recall here the concrete operations which are used in the deflnition 
of the concrete semantic rules depicted in Fig. The reader may refer to [M] 
for a complete description of all operations but the last one, SPLIT, that is brand 
new. 

- EXTC is used at clause entry: it extends a substitution on the set of variables 
occurring in the body of the clause. 

- RESTRC is used at clause exit: it restricts a substitution on the set of variables 
occurring in the head of the clause. 

- RETRG is used when a literal I occurring in the body of a clause is ana- 
lyzed. Let {xi^, . . . ,Xi^} be the set of variables occurring in 1. This opera- 
tion expresses a substitution on variables Xi ^ , • . . , Xi^ in terms of the formal 
parameters X\, . . . ,Xn- 

- EXTG is used to combine the analysis of a built-in or a procedure call (ex- 
pressed in terms of the formal parameters xi, . . . , x„) with the activating 
substitution. 

- UNIF-FUNC and UNIF-VAR are the operations that actually perform the unifi- 
cation of equations of the form Xj = xj or Xi^ = f{xi ^, . . . , Xi„), respectively. 

- SPLIT is a new operation: given a substitution 9 and a goal g, it partitions 
g into the set of atoms g.d which do not satisfy the corresponding delay 
declarations, and then are not executable, and the set of atoms g.e which 
satisfy the corresponding delay declarations, and then are executable. 

The deflnition of the concrete semantic rules proceeds by induction on the 
syntactic structure of program P. Rule Ri defines the result of executing a pro- 
cedure call: this is obtained by executing any clause defining it. Rule R2 defines 
the result of executing a clause: this is obtained by executing its body under 
the same input substitution after splitting the body into two parts: executable 
literals and delayed literals. Rule R3 defines the result of executing the empty 
goal, generating a successful output substitution. Rule R4 defines a deadlock sit- 
uation that yields a definite deadlock information S. Rules R 5 to Rg specify the 
execution of a literal. First, the literal is executed producing an output substitu- 
tion 03; then reexecutable atoms are (re)executed through the auxiliary relation 
{ 03 ,g-r) I — {^ 4 , 9 -f)' its effect is to refine 9^ into 04 and to remove from g_r 
the atoms that are completely solved in 04 returning the new list of reexecutable 
atoms g-r; Anally, the sequence of delayed atoms with the new substitution 04 
is partitioned in two sets: the atoms that are still delayed and those that have 
been awakened. Rules R5 and Re specify the execution of built-ins and use the 
unification operations. Rules Rj and Rg define the execution of an atom a 
The reexecutable rules defining the auxiliary relation 1 — can be easily 
obtained according to the methodology in m- 

The concrete semantics of a program P with delay declarations is defined as a 
fixpoint of this transition system. We can prove that this operational semantics is 
safe with respect to the standard resolution of programs with delay declarations. 
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c is a clause defining p 
(61, c) I — > (9',k) 

R1 

(e,p) I — s- {6',k) 



R3 

{e,< >,<><>,) ^ (e,v) 



:= g-e\b 
b := Xi = Xj 
6»i = RESTRG(6, 9 ) 

92 = UNIF_VAR(6»i) 

03 = EXTG(6,0,02) 
(93,g.r) I — (04,3-r) 
=SPLIT(04,fl-d) 
{94,g-d,g-eUg-e,gr) i — > (9',k) 

R,5 

(G,g-d,g-e,g-r) i — > {9' , k) 



:= g-e\a 

a :=p{xi ^, . . . ,®i„) 

01 = RESTRG(a, 0) 

(01, p) I S- (92,1^) 

03 = EXTG(a,0,02) 
(93,g-r) I — (04,0-r) 
(fl_d,5^e) =SPLIT(04,fl-d) 
(04, g-d, g.e U g'.e, gr) i — > (0', k) 

R7 

{d,g-d,g-e,g-r) i — > (0 ',k) 



c:=h:-g 
01 = EXTC(c, 0) 

(5_d,5_e) = SPLIT(0i,fl) 
{9i,g_d,g_e, < >) ' — s- (02, k) 

0' = RESTRC(c, 02) 

R2 

(0,c) ^ (0 ',k) 



either gjl > or gjr > 

R4 

{9,g_d,< >,g-r) i — s- (0,5) 



:= p_e \ b 

b~Xi = f{Xi^,. . -,XiJ 

01 = RESTRG(6, 0) 

02 = UNIF_FUNC(b, 0i) 

03 = EXTG(fe, 0,02) 
(03,0-r) I — (94,g-r) 
(fl_d,5fe) =SPLIT(04,P-d) 
{di,g-d,g-e'Jg'-e,gr) I — > (0',k) 

R6 

{d,g-d,g-e,g-r) i — > (0 ',k) 



p_e := p_e \ a 
a ;= p(®ii, . • • ,**„) 

01 = RESTRG(a, 0) 

(01, p) ^ (02,5) 

03 = EXTG(a,0,02) 
(03,3-r.a) I — S-r (04,0-r) 
(p_d,pfe) = SPLIT(04,p-d) 
(04,p-d,p-eup(e,pr) I — > (0 ',k) 

R8 

(d,g-d,g-e,g-r) i — s- {9' , k) 



Fig. 2. Concrete semantic rules 
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4 Collecting and Abstract Semantics 

As usual in the Abstract Interpretation approach | 9I10| . in order to define an 
abstract semantics we proceed in three steps. First, we depict a collecting se- 
mantics, by lifting the concrete semantics to deal with sets of substitutions. 
Then, any abstract semantics will be defined as an abstraction of the collecting 
semantics: it is sufficient to provide an abstract domain that enjoys a Galois 
connection with the concrete domain p{Subst), and a suite of abstract opera- 
tions that safely approximate the concrete ones. Finally, we draw an algorithm 
to compute a (post-)fixpoint of an abstract semantics defined this way. 

The collecting semantics can be trivially obtained from the concrete one by 

- replacing substitutions with sets of substitutions; 

- using /i, standing for possible deadlock, instead of S] 

- redefining all operations in order to deal with sets of substitutions (as done 
in [H]). 

In particular, the collecting version of operation SPLIT, given a set of substitu- 
tions 0, will partition a goal g into the set of atoms g.d which do not satisfy the 
corresponding delay declarations for some 9 G 0, and the set of atoms g_e which 
do satisfy the corresponding delay declarations for some 9 G 0. Notice that this 
approach is sound, i.e., if an atom is executed at the concrete level then it will 
be also at the abstract level. However, since some atoms can be put both in g_d 
and in g_e some level of imprecision could arise. 

Once the collecting semantics is fixed, deriving abstract semantics is almost 
an easy job. Any domain abstracting substitutions can be used to describe ab- 
stract activation states. Similarly to the concrete case, we distinguish among 
input states, e.g., (P,p) where (3 is an approximation of a set of activation sub- 
stitutions, and output states, e.g., {/3',k) where /3' is an approximation of a set 
of output substitutions and k G {/i, is an abstract deadlock state. Clearly, 
the accuracy of deadlock analysis will depend on the matching between delay 
declarations and the information represented by the abstract domains. It is easy 
to understand, by looking at the concrete semantics presented above, that very 
few additional operations should be implemented on an abstract substitution 
domain like the ones in leimi , while a great amount of existing specification 
and coding can be reused for free. 

Fig- IS] reports the final step in the Abstract Interpretation picture described 
above: an abstract transformation that abstracts the concrete semantics rules. 
The abstract semantics is defined as a post-fixpoint of transformation TAB on 
sets of abstract tuples, sat, as defined in the picture. An algorithm computing 
the abstract semantics can be defined by simple modification of the reexecution 
fixpoint algorithm presented in |15| . The reexecution function is in the spirit 
of [IS]. It uses the abstract operations REFINE and RENAME, where 

- REFINE is used to refine the result j3 of executing an atom by combining it 
with the results obtained by reexecution of atoms in the reexecutable atom 
lists starting from j3 itself; 

- RENAME is used after reexecution of an atom a: it expresses the result of 
reexecution in terms of the variables Xi^ ,■ ■ ■ , Xi^ occurring in a. 
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TAB(sat) = {{P,p, iP' , k)) : (P,p) is an input state and (/?', k) = Tp{P,p, sat)}. 



Tp{P,p, sat) = UNI0N((/3i, Ki) . . . , (/3„, «„)) 
where {Pi, Ki) = Tc{P, d, sat), 

Cl, ... ,c„ are the clauses defining p. 

Tc(P,c, sat) = (RESTRC(c,/3'),«;) 

where (P',k) = Tb{ETTC{c, P), g-d, g_e, < >,sat), 

{g~d, g-c) — SPLIT(/3, b) where b is the body of c. 

Tb{P, <>,<>,<>, sat) = (P, v). 

TbiP, g.d, < >, g_r, sat) = (P, p.) 

where either g_d or gjr is not empty. 

TbiP, 9-d, l-9-e, 9-r, sat) = Tb{P4,9-d, 9-e-9-e, 9-r, sat) 



where 


{g-d,g_e) = SPLIT(/34,5-d) 






{Pi, 9-r) = Tr{P 3 ,g-r,sat) 


ii K, = V, 




Tr{P3,9-r.l, sat) 

da =EXTG(Z,d,d2), 


li K = p. 




(d 2 ,K) = sat{Pi,p) 


if Z is p{- ■ •) 




(UNIF_VAR(di),!2) 


if 1 is Xi = Xj , 




(UNIF_FUNC(l,di),z^} 
Pi = RESTRG(l,/3). 


if 1 is Xi = /(■ ■ 


Tr{P, (ai, . . . 


, an), sat) = \~\i—i{Pi, gi) 




where 


{Po,9o) = {P, {ai,...,an)) 






Pi+i = REFINE(di, TriPi, ai, sat), ..., 


TriPi, an, sat)) {i > 1) 




gi+i = {ai i e {1, . . . , n} and (•, p) 


= TriPi, Oi, sat)} 


Tr(P, a, sat) 


= (RENAME(a,d2),K) 




where 


iP 2 ,k) = sat{Pi,p) 
Pi = RESTRG(a,d). 


if a is p(- • •) 



Fig. 3. The abstract transformation 



As already observed before, most of the operations that are used in the algo- 
rithm are simply inherited from the GAIA framework M- The only exception 
is SPLIT, which depends on a given set of delay declarations. 

The correctness of the algorithm can be proven the same way as in m and 
m- What about termination ? The execution of terminates since the number 
of literals in g_d and g_e decreases of exactly one at each recursive call. The fact 
that the execution of Tp terminates depends on some hypothesis on the abstract 
domain such as to be a complete lattice (when this is not the case, and it is just 
a cpo, an additional widening operation is usually provided by the domain). 
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Example 2. Consider again the program PERMUTE illustrated above. Using one 
of our domains for abstract substitutions, like Pattern (see j5T20| ). and starting 
from an activation state of the form permCground, var) our analysis returns the 
abstract qualified answer (perm(ground, ground), z/), which provides the infor- 
mation that any concrete execution, starting in a query of perm with the first 
argument being ground and the second one being variable, is deadlock free. 

5 Conclusions 

The framework presented in this paper is part of a project aimed at integrating 
most of the work, both theoretical and practical, on abstract interpretation of 
logic programs developed by the authors in the last years. The final goal is to get 
a practical tool that tackles a variety of problems raised by the recent research 
and development directions in declarative programming. Dynamic scheduling is 
an interesting example in that respect, as most of current logic programming 
environments integrate this feature. 

In the next future, we plan to adapt the existing implementations of GAIA 
systems in order to practically evaluate the accuracy and efficiency of the this 
framework. 

Acknowledgments. This work has been partially supported by the Italian 
MURST Projects “Interpretazione Astratta, Type Systems e Analisi Control- 
Flow”, and “Certificazione automatica di programmi mediante interpretazione 
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Abstract. Dependencies play a major role in the analysis of program 
properties. The analysis of groundness dependencies for logic programs 
using the class of positive Boolean functions is a main applications area. 
The precision of such an analysis can be improved through the inte- 
gration of either pattern information or type information. This paper 
develops an approach in which type information is exploited. Different 
from previous work, a separate simple analysis is performed for each sub- 
type of the types. If the types are polymorphic, then dependencies for 
specihc type instances are derived from the analysis of the polymorphic 
typed program. 



1 Introduction 

Dependencies play an important role in program analysis. A statement “pro- 
gram variable X has property p” can be represented by the propositional vari- 
able xP and dependencies between properties of program variables can be cap- 
tured as Boolean functions. For example, the function denoted by — >■ 

specifies that whenever x has property p then so does y. In many cases, the 
precision of a dataflow analysis for a property p is improved if the underlying 
analysis domain captures dependencies with respect to that given property. The 
analysis of groundness dependencies for logic programs using the class of posi- 
tive Boolean functions is a main applications area. It aims at identifying which 
program variables are ground i.e. cannot be further instantiated. The class of 
positive Boolean functions, Pos consists of the Boolean functions / for which 
f{true , . . . , true) = true. 

One of the key steps in a groundness dependency analysis is to characterise 
the dependencies imposed by the unifications that could occur during execution. 
If the program specifies a unification of the form termi = term2 and the variables 
in termi and term2 are {Xi, . . . , X^} and {Fi, . . . , F„} respectively, then the 
corresponding groundness dependency imposed is (xi A - • -AXm) ^ (yiA - ■ -Ayn) 
where the groundness of a program variable X is represented by the propositional 
variable x. This formula specifies that variables in termi are (or will become) 
ground if and only if the variables in term2 are (or do) . It is possible to improve 
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the precision of an analysis if additional information about the structure (or 
patterns) of terms is available. For example, if we know that termi and term ,2 
are both difference lists of the form Hi — Ti and H 2 — T 2 , respectively, then 
the unification termi = term 2 imposes the dependency {hi o ft. 2 ) A (ti O 12 ) 
which is more precise than {hi Ati) O (/12 At 2 ) which would be derived without 
the additional information. This has been the approach in previous works such 
as I20I24I8I11I2] where pattern analysis can be used to enhance the precision of 
other analyses. 

Introducing pattern information does not allow to distinguish between e.g. 
bounded lists such as [1,X, 3] and open ended lists such as [1,2|Z] because the 
open end can be situated at an arbitrary depth. Making such distinction re- 
quires to consider type information. The domain Pos has been adapted to do 
so in [5] where each type was associated with an incarnation of Pos. However, 
that analysis was for untyped programs and each incarnation was developed in a 
somewhat ad-hoc fashion. The model based analysis of [14] is also related. Here, 
the models of the program, based on different pre-interpretations express differ- 
ent kinds of program properties. But again, the choice of a pre-interpretation is 
on a case by case basis. Others in one or another way annotate the types with 
information about the positions where a variable can occur. This is the case in: 
1261^ : the binding time analysis of |^; and also in j2T| which uses types and 
applies linear refinement to enrich the type domain with Pos-like dependencies. 
Most close to our approach is the work of [1^ which associates properties with 
what we call in this paper the constituents of the type of the variable (the types 
possible for subterms of its value). In that work, unifications are abstracted 
by Boolean formulas expressing the groundness dependencies between different 
constituents. The main difference is that they construct a single compiled clause 
covering all constituents while we construct one clause for each constituent. A 
feature distinguishing our work from the other type based approaches is that we 
have an analysis for polymorphic types which eliminates the need to analyze a 
polymorphic predicate for each distinct type instance under which it is called. 

Type information can be derived by analysis, as e.g. in PITS] ; specified by 
the user and verified by analysis as possible in Prolog systems such as Ciao [16] ; 
or declared and considered part of the semantics of the program as with strongly 
typed languages such as Godel [17], Mercury [28] and HAL [13]. The analysis as 
worked out in this paper is for strongly typed programs. 

The next section recalls the essentials of Pos. Section E] introduces types and 
defines the constituents of a type. Section 0] develops the analysis for monomor- 
phic types, it defines the abstraction for different kinds of unification and proves 
that they are correct. Section El deals with the polymorphic case. It describes 
how to abstract a call with types that are an instance of the polymorphic types 
in the called predicate’s definition. It proves that the results of the polymorphic 
analysis approximate the results of a monomorphic analysis and points out the 
(frequent) cases where both analyses are equivalent. Section E] discusses applica- 
tions and related work. 



408 M. Bruynooghe, W. Vanhoof, and M. Codish 

2 Analyzing Groundness Dependencies with Pos 

Program analysis aims at computing finite approximations of the possibly infinite 
number of program states that could arise at runtime. Using abstract interpre- 
tation approximations are expressed using elements of an abstract domain 
and are computed by abstracting a concrete semantics; the algebraic properties 
of the abstract domain guarantee that the analysis is terminating and correct. 

The formal definition of Pos states that a Pos function (f describes a 
substitution 6 (a program state) if any set of variables that might become 
ground by further instantiating 0 is a model of (p. For example, the models 
of If = X A {y ^ z) are {X, Z}, {X, Y, Z}}. We can see that f describes 

6 = {X/a,Y/ f{U,V)), Z/g{U)} because under further instantiation X is in all 
of the models and if U is in a model (becomes ground) then so is Z. Notice that 
6 = {X/a} is not described by f as {X/a,Y/a} is a further instantiation of 9 
and {X,Y} is not a model of f. Pos satisfies the algebraic properties required 
of an abstract domain [3]. See also m for more details. 

A simple way of implementing a Pos based groundness analysis is described 
in [3 and is illustrated in Figure [TJ For the purpose of this paper it is sufficient 
to understand that the problem of analyzing the concrete program (on the left 
part of Figure [1]) is reduced to the problem of computing the concrete semantics 
of the abstract program (in the middle and on the right). The result is given 
at the bottom of the figure. For additional details of why this is so, refer to [Zl 
rmT 2 ^ . The least model of the abstract program (e.g. computed using meta- 
interpreters such as those described in 02!) is interpreted as representing the 
propositional formula Xi O X 2 and (a;iAa; 2 ) ^ x^ for the atoms rotate(Xi, A 2 ) 
and append ( Ai, A 2 , A 3 ) respectively. This illustrates a goal-independent anal- 
ysis. Goal-dependent analyses are supported by applying Magic sets or similar 
techniques (see e.g. |7]). 



Concrete rotate 


Abstract rotate 


Auxiliary predicates 


rotate(As.ys) 


rotate(As.Fs) 


iff (true . []) . 


append ( As. Bs. As) . 


appendCAs.Bs. As) . 


if f (true . [true 1 As] ) 


append (Bs. As. Ts) . 


append (Bs. As. Us) . 


iff (true .As) . 
if f (false .As) 


appendCAs. Vs.Zs) 

As = n. 

Ys = Zs. 

3jppend(.Xs ,Ys ,Zs) 

As = [A|Asl]. 

Zs = [A|^sl]. 
appendCAsl . Ts.Zsl) . 


appendCAs.Ts.Zs) 
iff(As.[]). 
iff (Us. [^s]). 
append(As.Us.Zs) 
iff(As.[A,Asl]). 
iff (.Zs, [A, Zsl ]') . 
appendCAsl.Fs.Zsl) . 


member(false.As) . 



rotate (A, A) . append (true .true .true) . 
Least model (abstract rotate); appendCfalse.F. false) . 

append(A. false. false) . 



Fig. 1. Concrete and abstract programs; least model of the abstract program 
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3 About Terms and Types 

We assume familiarity with logic programming concepts mm- We let Term 
denote the set T{E, V) of terms constructed from the sets of function symbols 
E and variables V . Types, like terms are constructed from (type) variables and 
(type) symbols. We denote by T the set of terms T{S-j-,Vr) (or types in this 
case) constructed from type symbols Ej- and type variables Vj-. We assume that 
the sets of symbols, variables, type symbols and type variables are fixed and 
disjoint. We write t:r to specify that term t has type r and f /n to specify that 
(function or type) symbol / has arity n. Besides the usual substitutions which 
are mappings from variables to terms, we also have type substitutions which are 
mappings from type variables to types. 

We assume a standard notion of strong typing as for example in Mercury [ 2 ^ . 
This means that each predicate is associated with a single type declaration and 
that programs are well typed. Hence, one can associate a unique type with 
every term and variable in a program clause. A type containing type variables is 
said to be polymorphic, otherwise it is monomorphic. The application of a type 
substitution to a polymorphic type gives a new type which is an instance of the 
original type. For each type symbol, a unique type rule associates that symbol 
with a finite set of function symbols. 

Definition 1. The rule for a type symbol h/n G Ej- is a definition of the form 
h{V) — > /i(ti) ; . . . ; fk{fk). where: V is an n-tuple from V-p; for 1 < i < k, 
fi/m S E with fi an m-tuple from T ; and type variables occurring in the right 
hand side occur in V . The function symbols {/i, . . . , fk} are said to be associated 
with the type symbol h. A finite set of type rules is called a type definition. 

Example 1. The keyword type introduces a type rule: 

type list(T) > [] ; [T I list(T)]. 

The function symbols [•] (nil) and [-I-] (cons) are associated with the type sym- 
bol list. The type definition specifies also the denotation of each type (the set 
of terms belonging to the type). For this example, terms of polymorphic type 
list(T) are variables (typed list(T)), terms of the form [], or terms of the form 
[ti\t 2 ] with ti of type T and t 2 of type list{T). As T is a type variable we cannot 
determine or commit to its structure under instantiation. Hence only a variable 
can be of type T. Applying the type substitution {T/int} on list{T) gives the 
type list{int). Terms of the form [ti|f2] are of type list{int) if ti is of type int and 
<2 is of type list{int). Type instances can also be polymorphic, e.g. list{list{T)) . 

The next definition specifies the constituents of a type t. These are the 
possible types for subterms of terms of type t. 

Definition 2. Let h{f) — > /i(d) ; /fc(A) be an instance of a rule in 

p and T an argument of one of the fi{fi). We say that t is a p-constituent of 
h{f). The constituents relation is the minimal pre- order (reflexive and transitive) 
<p-. T xT including all pairs t' p<p r such that t' is a p-constituent of t. The set 
of p- constituents of t is Constituents p{r) = { r' G T | r' r } . When clear 
from the context we omit p and write ^ and Constituents. 
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Example 2. With listjX as in Example [T] and the atomic type int, we have: 

— T < list{T), list{T) ^ list{T), int ^ list{int), int ^ int, listiT) ^ list{list{T)), 

T ^ list(list{T)) , list{list{T)) ^ list{list{T)) , T <T, . . . 

— Constituents (int) = {int}, Constituent s{T) = {r}, Constituents{list{T)) = 

{T,list{T)} , Constituents{list{int)) = {int,list(int)}. 

To ensure that analyses are finite, we restrict types to have finite sets of con- 
stituents. This is common as a type with an infinite set of constituents is not well 

defined. For example, consider the definition: type t(T) > f(t(t(T))). 

The type t(T) is defined in terms of its constituent type t{t{T)), which in turn 
is defined in terms of its constituent type t{t{t{T))), and so on. 

The following defines the instantiation of terms with respect to a given type. 

Definition 3. Let p define the types r and t' . We say that the term t:r' is r- 
instantiated (under p) if: (1) r is a eonstituent of t' ; and (2) there does not 
exist a well-typed instance ta:r' containing a variable of type r. The predicate 
p(.{t\T') is true if and only if t:r' is t -instantiated. For a set of typed vari- 
ables of interest V and a well typed substitution 9, we denote by pr{9,V) = 
{ X\t' \ pr{X9\T') }. This is the subset of the variables of interest which 
are t -instantiated by 9. 

If t' has no constituents of type 
T then we do not consider t\r' as 
T-instantiated because no instance of 
any term of type t' can have a sub- 
term of type r. In the case t\T where 
T is a polymorphic parameter (and T 
has no constituents of type r), the in- 
tuition is that for some instance t' of 
T, it could be the case that t:r' should 
not be considered r-instantiated. Figure El illustrates the Hs<(jnt)-instantiation 
and mt-instantiation for several terms of type list{int). First note that both 
list{int) and int are constituents of list{int). Hence, Pust{int)i[^j X]) is true 
because all list(int)-suhteims of well-typed instances of [i,X] are instantiated; 
and Piist{int){[MX]) is false because the subterm X:list{int) is a variable. Also 
pLint{[l\X\) is false as e.g. [l,y|Z] is an instance with the variable Y of type 
int. Note that p,int{s) — l Pust(int){s). In general, the following property holds: 

Proposition 1. For constituent types ti ^ T 2 and any term t, p-nit) — >■ 

We observe that classical groundness for a typed term t:r can be expressed 
with respect to types instantiation by requiring t to be instantiated with respect 
to all constituents of r. 

ground{t) O A { p(..{t:T) | Ti € Constituents{T) } . (1) 



tdist{int) 


f-^list(int) (^) 


f-f'int (t) 


[1,2] 


true 


true 


[1,^] 


true 


false 


[1|A] 


false 


false 


[] 


true 


true 



Fig. 2. The r-instantiation of some 
listfint) terms 
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4 Pos{'T) in a Monomorphic Setting 

We let the propositional variable x'^ denote the predicate ^p{X:t') meaning that 
typed program variable X:t' is instantiated with respect to type t. Instantiation 
analysis using Pos{T) generalises groundness analysis with Pos. Informally, a 
positive Boolean formula (p, representing r-instantiation dependencies, describes 
a substitution 9 if any set of variables that might become r-instantiated by fur- 
ther instantiating 0 is a model of (p. The abstraction and concretization functions 
are formalised as: 

Definition 4. Let V he a set of (typed) variables of interest and t a type. The 
T -abstraction (in terms of models) of the set 0 of well-typed substitutions and 
the T -concretization for the positive Boolean function if are: 

ar{0) = { /ir(6*cr) I 6* G 0, a is a well typed substitution } 

TrW = { ^\oir{{e}) C if ] 

Example 3. Let V = [ X:list{int),Y:int, Z:list{int) } and 6* = { X i— i \Y\Z\ }. 
Then, aiist(i„t)({^}) has models {0, {x,z} } (observe that Y:int is not list{int)~ 
instantiated because listfinf) is not a constituent of int) and ai„t{{9}) has 
models { 0, {y}, {z}, {x, y, 2 } }. These sets of models correspond respectively to 
the formulae x z and a; O {y A z). 

In a classic groundness analysis, the unification A = [ArjAls] is abstracted 
as a GG (a; A a;s). Indeed, we assume that any subterm of the term that A is 
bound to at runtime could unify with any subterm of the terms bound to X 
or Xs. In the presence of types we know that A and [XlAls] are both of the 
same type (otherwise the program is not well-typed). In addition, we know that 
all unifications between subterms of (the terms bound to) A and [Al|Xs] are 
between terms corresponding to the same types. So in this example (assuming 
both terms to be of type list{int)), we can specify a xs for type list{int) 
and a O (x A xs) for type int. It is important to note that the interpretations 
of the variables in a -fA xs and in a -fA (x A xs) are different. The former refers 
to subterms of type list{inf) whereas the latter refers to subterms of type int. 
These intuitions are formalised in the following definitions and theorems. 

Definition 5. The r abstraction of a normalised typed logic program P is ob- 
tained by abstracting the equations in P. An equation of the form X = Y with X 
andY of type t' is abstracted by iff(X, [Y] ) (implementing x ^ y) ifr ^ r' and 
otherwise it is abstracted by true. An equation of the form X = f{Yi , . . . , Yn) 
with typed variables X:t' , Ypri, . . . , is abstracted by iff(X, [W\ ,.. ., W^] ) 

(implementing x -frA w\ A ■ ■ ■ Wk) if t < t' and otherwise it is abstracted by true 
where {Wi , . . . , Wk} = {L)|l < i < n, r ^ r^}. 

Theorem 1. Correctness. Let E be of the form X = Y or X = /(hi, . . . , F„), 
p a positive Boolean function on a set of variables V including the variables in 
E of a type having r as constituent, and p' the r-abstraction of E. If 9 € Jt{p) 
and a = mgu{E) then 9a\v G ^r{p p')- 
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Proof. If X ^ Constituents{T') then ^p' = true hence (p t\ (f' = Lp. Moreover, 
is closed under instantiation, hence 9u\v C 7r((/3 A p'). 

Otherwise, observe that 7 t(<P A p') = ')t{p) O 'yrip') hence it suffices to show 
that 9a\v € 7r(i^) and 9a\v S "frip')- The former holds because the set "trip) 
is closed under instantiation. For the latter, we distinguish: 

- Case X = Y\ X9a = Y9a hence pr{X9a) iff fj,T{Y9a) and 9a\v G 7 t( 2 : -o- 
y) = lr{p')- 

- Case X = /(Yi, . . . , Fji): a is an mgu hence iir{X9cr) iff 

fj,.^[f(Yi, . . . ,Yn)9a). X9a is definitely instantiated, hence, whether or not 
r = r', we have that pr{X9a) iff /\{pLr{Xi9cr)\T ^ n} and 9a\v S 'jrix O 
A{?/»|r ^ Ti}) = jrip')- 

□ 

Having shown that the r-abstraction of unification is correct, we can rely 
on the results of [7] for the abstraction of the complete program, for the com- 
putation of its least model and for the claim that correct answers to a query 
^ p{Xi, . . . , Xn) belong to the concretisation of the Pos(T)-formula of the 
predicate p/n. Basic intuitions are that the PosifT) formula of a single clause 
consists of the conjunction of the Pos{T) formulas of the body atoms and that 
the Pos{T) formula of a predicate consists of the disjunction (lub) of the Pos{T) 
formulas of the individual clauses defining the predicate. 

The adaptation of the implementation technique of Section |2]for an analysis 
of append (list (int) , list (int) , list (int) ) is as follows: 



Abstraction for type constituent list{int) 
append_list_int(Xs,Ys,.Zs) 
iff(Xs,[]), 
ii±(.Ys,[Zs]) . 

append_list_int(Xs,Ys,.Zs) 
iff(Xs,[Xsl]), 
iff (.Zs, [Zsl ]) , 

append_list_int (Xsl , Ys,Zsl) . 



Abstraction for type constituent int 
append_int(Xs, Ys,.Zs) 
iff(Xs,[]), 
iff(Ys,[Zs]) . 
append_int(Xs,Ys,.Zs) 
iff(Xs,[X,Xsl]), 
iff(Zs,[X, Zsl]), 
append_int (Xsl , Ys,Zsl) . 



The least model of append_int/3 expresses the Pos(mt)-formula z x Ay, 
i.e. that all subterms of Z of the type int are instantiated iff those of X and Y 
are. The least model of append_list_int/3 expresses the Pos(Hst(int) )-formula 
xA{y O z), i.e. that all subterms of X of type list{int) are instantiated (in other 
words the backbone of the list is instantiated when append/3 succeeds) and that 
those of Y are instantiated iff those of Z are instantiated. Classical groundness, 
is obtained by composing the two models, using Equation 0 in Section 0 
append(X,Y,Z) append_list_int(Xl,Yl,Zl) , append_int (Xe, Ye ,Ze) , 
iff (X, [Xl,Xe]) , iff (Y. [Yl,Ye]) , if f (Z, [Z1 ,Ze] ) . 

As int :< list{int), the analyses of the two constituents is related. In fact, 
the model of append_list_int/3 can be used to initialise the fixpoint compu- 
tation of the model of append_int/3 as follows from the next proposition (see 
Appendix I A . 2 1 for the proof). 



Pos{'T): Analyzing Dependencies in Typed Logic Programs 413 



Proposition 2. Let p/n be a predieate in a typed logie program and t and t ' 
types such that t' < t. Let Y denote the arguments Yp.Ti of p/n such that t' ^ Ti 
but T y/ Ti. Denote the results of the t- and t' - analyses of p/n by p and tp' and 
let be the conjunction of the variables in Y . Then p t\ if ^ p' . 

5 Polymorphism in Pos{'T) 

Type polymorphism is an important abstraction tool: a predicate defined with 
arguments of a polymorphic type can be called with actual arguments of any 
type that is an instance of the defined type. For example, the append/3 predicate 
from Section |4] can be defined with respect to the polymorphic type definition 
appendClist (T) ,list(T) ,list(T)), stating that its arguments are lists of the 
same type T. Abstracting append/3 for this definition results in the same ab- 
stractions as in Section 01 but with list(/T) and T replacing list(int) and int. 

The results of the analysis with type variables is correct for any choice of types 
instantiating them (e.g., list(int) and int, or list (list (inf)) and list(int) when 
append/3 is called with actual types list(int) or list(list(int)) respectively). It is 
also possible to obtain the result of the analysis for each type-instance by which 
it is called and sometimes this gives a more precise result. However, it is more 
efficient to analyze the definition once for its given polymorphic types, and then 
derive the abstractions of a particular call from that result. 

The need for such an approach is even more crucial when analyzing large 
programs distributed over many modules. It is preferable that an analysis does 
not need the actual code of the predicates it imports (and of the predicates called 
directly or indirectly by the imported predicates) but only the result of the call 
independent analysis. See [251412111 for discussions about module based analysis. 

Example /. Consider a predicate p/2 with both arguments of type list(list(inf)) . 
The program and its abstractions for the int, list(int) and list (list (inf)) are as 
follows: 



Concrete definition 


Abstractions 


p(X,Y) append(X,X,Y) . 


p_list_list_int(X,Y) append_list_T(X,X,Y) . 

p_list_int(X,Y) append_T(X,X,Y) . 

p_int(X,Y) appendix (X,X,Y) . 



Intuitively, it is clear that the constituent list (list (int)) from the call to 
append/3 corresponds to the constituent list(T) in append/3’s definition. Hence, 
instead of computing the list(list(int))-ahstTa,ction of append/3, its list(T)~ 
abstraction can be used. Likewise, the constituents list(inf) and int from the 
call both correspond to the constituent T in the definition, hence also their 
abstractions. 

To formalize the relationship between the constituents of the actual types 
and those of the formal types, we introduce the notion of a variable typing. 
Definition 6. A variable typing f is a mapping from program variables to types; 
dom(f) is the set of variables for which the mapping is defined; Xf denotes the 
type of X under the variable typing f. Given variable typings C, and C over the 
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same domain, C,' is an instance of C, if , for every X G dom{C) there exists a type 
substitution f such that Xf = Xff. 

The notion of Constituents extends in a straightforward way to variable typ- 
ings. In a well-typed program, the types of the arguments of a call are always at 
least as instantiated as the types of the corresponding arguments in the predi- 
cate definition. Hence the constituents occurring in a variable typing of a call 
p{Xi , . . . , X„) can be related to the constituents of the variable typing ( of the 
head p{Yi , . . . , Yn) as follows: 

Definition 7. Consider variable typings f' and f with an instance off. The 
type mapping between C, and (' is the minimal relation R^, : T x T such that: 

- If X/ti G C and X/T 2 G C then (ti,T 2 ) G . 

- If (ti,T 2 ) G R^, and T 2 G Vj- then Vr G C onstituents{Ti) : (r, T 2 ) G . 

- //(ti,T 2 ) G and T 2 = h(Vi, ..., 14)^2 and ti = h{V\, . . . ,Vn)fi and 

h{Vi,...,Vn) — !> ;... ; fi{ri^, . . . ,n^^) is the type rule for 

h/n then, for all n., ^,6) G 

The type function cj)^, ■.l'\-^2^is defined for constituents of the most instanti- 
ated type C': r') G 

When C and f' are obvious from the context, we will write R and </>(r). 

Example 5. The type mapping and type function associated to the variable typ- 
ings ( = {X/list{T)} and (' = {X / list{list{int))} are repectively: 

- R= {{list{list{int)),list{T)), {list{int) ,T) , (mt,T)} and 

- 4> = {{list {list {int)), {list fr)}), {list{int),{T{), {int,{T{){. 

If Cf denotes the variable typing associated to the variables of the call, and C 
denotes the variable typing associated to the called predicate’s head variables, 
the mapping R expresses that the r-abstraction of a call corresponds to the 
</>(r)-abstraction of the called predicate. As an illustration, (f from Example |5] 
gives the mappings used in Example SI 

However, in general 4>{t) is not a singleton, as a constituent of the call can 
be mapped to itself and to one or more type variables in the polymorphic type 
definition. Consider for example a predicate q/4 and its abstractions: 



Concrete 


Abstraction w.r.t. int 


Abstraction w.r.t. 


pred q(int , int ,T,T) . 
q(X,Y,U,V) X=Y,U=V. 
q(X,Y,U,V) X=0. 


q_int(X,Y,U,V) 
iff (X, [Y]) . 
q_int(X,Y,U,V) 
iff(X,[]). 


q_T(X,Y,U,V) 
iff(U,[V]). 
q_T(X,Y,U,V) . 



T 



Suppose q(A,B,C,D) is a call with A,B,C and D of type int. The type 
substitution on the defined types is {T/int}, and hence 4>{inf) = {int,T{. A 
correct int-abstraction of the call should include both the int-abstraction and 
the T-abstraction from the definition, since in the polymorphic analysis, it was 
assumed that T does not have int as constituent. Hence, the inf-abstraction of 
the call becomes qJnt{A, B,C, D) A qTT{A,B,C,D). The formal definition of 
the T-abstraction of a predicate call is then as follows: 
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Definition 8. Let C' and C be the variable typings assoeiated respeetively to a 
eallp(Xi, . . . ,Xn) and the head of p’s definition; let t' € Constituents(f') ; The 
t' -abstraction ofp{Xi, . . . ,X„) is defined as t\{pjr{Xi, . . . ,X„)|r € 

Handling a predicate call in such a way, however, possibly causes some preci- 
sion loss. Indeed, one can verify that a monomorphic analysis of q(X,Y,U,V) for 
the type p (int , int , int , int) gives the formula ((x O y) A (u O u)) V a; while 
the conjunction of calls pJnt{X,Y,U,V),pTr{X,Y,U,V) gives the less precise 
formula ((x -O- y) V a:) A ((m O u) V true). However, the result is always safe: 

Theorem 2. Let p be a predicate definition and f and variable typings for 
the variables of p such that C,' is an instance of f. For t € Constituents{Cf) , 
let if’’’ denote the r-abstraction of p for the variable typing f, and similarly for 
t' S Constituents(f'), let ifi’’ denote the t' -abstraction of p for the variable 
typing . Then it holds that 'ifi’’ — >■ A{y>'^|r G fiir')}. 

Theorem Instates that the use of Definition [^safely approximates the result 
obtained by an analysis of the called predicate for the type instances used in 
the call. As the above example illustrates, the equivalence does not hold and 
some precision loss is possible. However, such precision loss occurs only when 
constituents of parametric type instances interfere with each other or with other 
types. In case there is no such interference (i.e. is a singleton), the results 

of call-independent analysis equal those of call-dependent analysis. We believe 
that interference is more the exception than the rule. Indeed, it only happens 
when type instances of two different type variables have a common constituent 
or when the instance of a type variable has a constituent common with the type 
of another argument. Even if the types do interfere, a loss of precision is avoided 
if the lub of the Pos(T) -formulas of each individual clause body is equal to 
the Pos(T) -formula of one of the clause bodies (the same for all types t). This 
could well be often the case in practice because different clauses of a program 
tend to establish the same degree of instantiatedness (or in case of recursion, the 
Pos(T)-formula of the base case implies the Pos(T)-formula of the recursive 
clause(s)): 

Corollary 1. With the same notations as in Theorem let Lpf denote the 
T-abstraction of the body of clause j of predicate p’s definition. Lf 4>{t') has 
only one element or there exists a clause k such that for all r S fiir'): ifl. = 
\/{(pj\j is a clause}, i.e. the r-abstraction of the body of clause k is the upper- 
bound of the T -abstractions of all clause bodies, then ifi’’ = A{i^'^|r G ^(r')}. 

Intuitively, one can say that some dependencies are ignored by analysing the 
predicate separately for each element in </>(t'), and that they are only partly 
recovered by taking the conjunction of the obtained formulas. We refer to Ap- 
pendix [XT| for the proofs of Theorem |2] and Corollary |T1 

6 Discussion 

The main goal of this research is to improve the precision of groundness depen- 
dencies by taking into consideration type information. Precision is improved for 



416 M. Bruynooghe, W. Vanhoof, and M. Codish 



two reasons: (a) when unifying terms (or variables) of the same type it is possible 
to refine the resulting dependencies (e.g. list elements with list elements, and list 
backbone with list backbone); and (b) computation paths which unify terms of 
different types can be pruned. 

While Pos{T) can improve the precision of groundness dependencies it is 
important also to note that the Pos{'T) formulas provide valuable information on 
their own. In future work we intend to use it to improve automated termination 
analysis which in turn will be used in a binding-time analysis for the off-line 
specialisation of logic programs (improving the work in [3].). 

Some preliminary experiments, using the implementation technique of 
indicate that our approach can be done more efficiently than the approach in 
m where a single model is computed, and where a program variable corresponds 
to several Boolean variables, one for each type constituent. The reason is that 
the computation of the least fixpoint of the abstracted program slows down more 
than linearly with the number of variables. Moreover, proposition |2] allows for 
extra savings by reusing results from one type constituent in the computation 
for other constituents. 
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A Proofs 

A.l Proof of Theorem E] and Corollary [T| 

In the formulation and proofs that follow, we consider a program construct under 
two variable typings ( and (' such that (' is an instance of (. With X a program 
variable, we denote with tx and the type of X in respectively ( and We 
relate the r'-abstraction of the construct for a type t' £ C onstituents{C,') with 
its (^(r')-abstractions. First, we consider a single unification. 

Lemma 1. With E an equality, let qX denote its r-ahstraetion for the variable 
typing f and and its t' -ahstraetion for the variable typing f . Then it holds 

that = f\{qf\T £ 

Proof. E is of the form X = .... Assume Yi, . . . are the variables in the rhs. 
such that t' £ C onstituents(TY.) ■ Then tp'^ = a; -£>■ t/i A . . . A Let (P{t') = 
{ti, . . . ,T„}. The variables . . . , Y^„ such that £ Constituent s{TYi^) are a 

subset of {Yi, . . . , Y„} and = x A . . . Ayi^, . Moreover, by construction 

of (p it holds that t' £ Constituents{TY.) if and only if 3xj £ Constituents{TYf) 
and hence Ui{^i i i } = {^i) • ■ ■ ) Yn}. Consequently, 

iP'^ = X yi A ... Ayn 

= (a; O yii A . . . A ) A . . . A (x £A A . . . A ) 

= A ... A □ 

Some properties of propositional logic (5 is a propositional formula): 

If yi : b[ ^ bi then A 6' — >-A bi (1) 

i i 

If Vi : 6' — 1 bi then V b'i — >-V bi (2) 

i i 

yi,j -.y {Abij) ^A {y b,j) (3) 

J 1 J 

The following lemma concerns the t'- and r-abstractions of a predicate definition. 

Lemma 2. Let p be a predicate definition; let and (pj j denote respectively 
the T-abstraction of p and of Bij, the body atom in the clause, for the 
type assignment f, and similarly, ip'^ and ipj ^ the r'-abstraction of p and Bij 
for the variable typing f . If for each body atom Bij: ipjj — >■ A{p \ ^\t £ 
then '0’’ — t A{y>'^|r £ (p{r')}. 

Proof. Assuming ipjj — >• A{plj\r £ (p{r')}, we prove ip'' -A A{p'\r £ (p{r')}. 
Let i?ij, . . . , be the body of the clause; let pf = A{pij\i £ {!,..., nj}} 
and ipj = A{ipfj\i £ {!,..., Uj}} be their respectively r- and r'-abstraction. 
Using the assumption, © and commutativity of A, we obtain: ipf — >■ A{:^J|t £ 

Using (13 we obtain: V ip'll — >-V ( A p''). 

j 3 

Using d2J we obtain: V ipY = ip^ — >• A {y p'' = A p''). □ 

3 tS0(t') 3 rG0(r') 
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From the above lemma, we derive two corollaries that we can use to prove Corol- 
larvfniD. ldlSp . A first one handles the first option in the condition of Corollary [TJ 
namely the case that 4>(t') = {r}, that is, when there is a one-to-one correspon- 
dence between t' in C' and t in 

Corollary 2. With the same notations as in Lemma, if has only one 

element and for each body atom: 'ijjJ j = ^\t G then G 

Proof. Immediate from the proof of Lemma [H □ 

The second corollary handles the case that the least upperbound of the r- 

abstractions of the individual clauses equals the r-abstraction of one of the 

clauses. 

Corollary 3. With the same notations as in Lemma 'if’P’Ij = G 

4>{t')} and there exists a clause k such that for all t G 
Lpl. = is a clause} then = A{<^'^|r G (P{t')} . 

Proof. With the notations of in Lemma[2|we now obtain ipf = A{(/?J|t G cP{t')}. 
Hence V V'l = ip^ =V ( A ip}). 

j 3 tG0(t') 

Using the assumption, \/ i A ip}) = A ipl = A . □ 

Now, we can prove Theorem by using Lemmas [I] and from above. 

Theorem Let p be a predicate definition; let denote the r-abstraction of 
p for the variable typing (; let ip'^ denote the r' -abstraction of p for the variable 
typing . Then it holds that ip'^ -A A{ip'^\r G <p{r')}. 

Proof. The formula ip'^ is computed by a bottom up fixpoint operator that, start- 
ing from the formula false for all predicates, recomputes the Pos (T)-formula 
of each predicate until a fixpoint is reached. The proof is by induction on the 
number of iterations. 

The predicate p is defined by the clauses Ci, . . . , Cm, and a clause Ci is a 
conjunction of body atoms Pi,i, . . . , Bi^m- 

— First iteration. Since Lemma [T] holds for the unifications, and the predicate 

calls in the body only introduce the formula false, we have for each body 
atom Bij that ipfj = A{ip}j\r G where tpfj denotes the r'-abstraction 

of Bij for variable typing (' and ip}j denotes the r-abstraction of Bij for 
variable typing (. Applying Lemma [2] results in tp'^ -A A{vj'^|t G 4>{t')}. 

— Induction step. Assume the formula holds after k iterations. For the abstrac- 
tion of p as constructed in iteration fc -|- 1, we have either by Lemma [I] (for 
the unifications) or by the induction hypothesis (for the predicate calls) that 
for each body atom Bij holds that ipj -A A{iplj\r G (p{r')}. 

Applying Lemma[2]on obtains: ip'^ -A A{i^'^|r G 4>{t')}. □ 

Corollary [T] on page I4I5I can be proven analogously to the proof of Theorem |21 
using Corollaries |5] and O instead of Lemma [21 
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A. 2 Proof of Proposition!^ 

Proposition Let p/n he a predicate in a typed logic program and t and r' 
types such that t' -< t . Let Y denote the arguments Yp.Ti of p/n such that t' ^ Ti 
hut T y/ Ti. Denote the results of the t- and t' - analyses of p/n hy p and tp' and 
let Ip he the conjunction of the variahles in Y. Then (p Aip ^ ip' . 

Proof. Let us denote by X the arguments of p/n not in Y and write ip{X,Y)., 
p’{X,Y) and tp{Y) instead of p, p' and ip. Moreover we assume without loss of 
generality that the arguments of p/n are p{X, Y). 

The proof is based on the observation is that there is a one-one correspon- 
dence between value assignments {x/v} that are models of the r-abstraction 
pipe) of a predicate q/m and the atoms q{v) that are computed during the 
computation of the least fixpoint of the abstracted program. With Pr and Pr' 
respectively the r- and r'-abstractions of the program, we proof by induction 
that p{u, v) S Tp^ t k implies p{u, true) G Tp^, f k. (We assume the least fixpoint 
of the iff/2 predicate is computed in advance.) 

Iteration 1. If p{u,v) G Tp^ f it means that Pr contains a clause Cr = 
p{X,Y) -It- Bi, . . . ,Bm with all Bi calls to iff/2 (r-abstractions of equalities) 
and that there is a substitution 9 = {X /u,Y /v, Zi/wi} such that Vi : Bi9 is 
true in the least model of iff/2 (note that the variables of Y do not occur in 
the body). Hence Pr> contains a clause Cr' = p{X, Y) ^ B [, . . . , B'^, C\,. . . ,Cn 
with the r'-abstractions of the equalities having Bi as their r-abstraction and 
the Ci r'-abstractions of equalities having true as r-abstraction. To prove that 
p(m, true) G Tp^, f 1 it suffices to prove that tr = {X /u, Y /true, Zi/wi, Z-i/truej 
makes the body of cp true (the variables of Z 2 occur in the body of Cr' but not 
in the body of Ct). To prove the latter, we show that the three kinds of atoms in 
the body of Cr' are true in the least model of ±ff/2 under the substitution tr: 

- Bi is the r-abstraction of an equation U = V . Obviously, B[ = Bi, and 
Bia = BiO is true in the least model of iff/2. 

- Bi is the r-abstraction of an equation U = f{V). Bi is of the form 
iff{U, \Vr\) with Vr the variables of V having r as a constituent of their 
type. Hence B' is of the form iff{U,[Vr,Vp]) with Vr> the variables of V 
having r' but not r as a constituent of their type. Note that a binds the 
variables of Vp to true. We know that Bi9 is true, that means either U and 
Vr are bound to true and thus also Bia is true or U and at least one of Vr 
are bound to false, also in this case, Bia is true. 

- Ci is of the form iff{. . .) with all variables not occurring in the body of Cr. 
All these variables are bound to true under a hence Cia is true. 

Iteration fc -|- 1. Assume p{u,v) G Tp^ f ^ + 1- The difference with the first 
iteration is the form of the clauses Cr and Cr' . The body of Cr now contains also 
calls of the form q{X' ,Y') (with Y( : Ti the arguments of q/m such that r' ^ Tj 
but r Ti). The body of Cr' contains corresponding calls q{X',Y'). We know 
that q{X', Y')9 G Tp^ \ k, hence, by induction hypothesis, q{X', Y')a G Tp^, f k. 
The other atoms in the body of Cr' are true for the same reasons as in the first 
iteration, hence the whole body is true under a and p{u, true) G Tp^, f fc + 1- 
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Abstract. Prolog tailoring technique, an optimization method to improve the 
execution speed of a procedure, is proposed in this paper. When a procedure is 
repeatedly called and the machine has a lot of callee-saved registers, optimizing 
prolog and epilog of the procedure can become an important step of optimiza- 
tion. Epilog tailoring supported by IBM xlc compiler has been known to im- 
prove a procedure’s execution speed by reducing the number of register- 
restoring instructions on exit points. In this paper, we propose a prolog tailoring 
technique that can reduce register-saving instructions at entry points. We can 
optimize prolog by providing multiple tailored versions of it on different exe- 
cution paths of the procedure and by delaying the generation of register-saving 
instructions as late as possible on each path. However, generating prolog inside 
diamond structures or loop structures will cause incorrectness or unnecessary 
code repetition. We propose a technique to generate efficient prolog without 
such problems based on Tarjan’s algorithms to detect SCCs (Strongly Con- 
nected Components) and BCCs (Bi-Connected Components). 



1. Introduction 

In a procedure call, some registers, called callee-saved registers, should preserve their 
values across the call; that is their values should be the same before and after the call. 
The callee guarantees it by saving those registers before starting the actual function 
body and restoring them later before leaving the code [2,3]. The register-saving in- 
structions are called a prolog, while the register-restoring ones called an epilog. Every 
time this procedure is called, the prolog and epilog should be executed. Eor frequently 
executed procedures, therefore, they consume significant amount of time and are an 
important source of optimization [4,5]. 

In order to reduce the overhead of prolog and epilog code, the traditional technique 
was to compute those callee-saved registers that are actually killed inside the proce- 
dure. They are, then, saved and later restored in the prolog and epilog code, respec- 
tively. In this paper, we propose techniques to further reduce the number of registers 
that need to be saved and restored by tailoring the prolog and epilog to different exe- 
cution paths. We observe that if the procedure has several execution paths, and if each 
path is modifying different sets of callee-saved registers, then, we may provide a 
different pair of prolog and epilog for each path. Since they are saving and restoring 
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only those registers that are killed in the particular path, we can reduce the size of 
them. 

Tailoring epilog has been implemented in some compilers, e.g. IBM xlc compiler, 
and the algorithm is explained in [12]. In [5], a brief mention on prolog tailoring has 
been made, but detailed algorithm is not published yet. In this paper, we provide the 
detailed algorithm and examples of prolog tailoring. The paper is organized as fol- 
lows. Section 2 explains the existing epilog tailoring technique and some related re- 
search. Section 3 explains the basic idea of the proposed prolog tailoring technique. 
Section 4 describes the proposed prolog tailoring algorithm in detail. Section 5 and 6 
gives out experimental results and a conclusion. Finally, Appendix A will show an 
example. 



2. Epilog Tailoring and Related Researches 

Epilog tailoring tries to minimize the number of register-restoring operations at each 
exit point. The basic technique is to split the exit point. By splitting it, the set of killed 
registers (therefore the set of should-be-restored registers) can be different at different 
exit points, and we can restore only those actually killed registers at each exit point. 

Fig. 1 shows an example. Fig. 1(a) is the prolog and epilog code generated without 
any tailoring process. In the procedure, r28, r29, r30, and r31 are killed; therefore they 
are saved and restored at the entrance and exit points. Fig. 1(b) shows the same pro- 
cedure with tailored epilog code. The original exit point is split into two: el and e2 in 
the figure. At the paths reaching el, the first exit point, r28 and r30 are killed, while at 
the path reaching e2, r29 and r3 1 are killed. Therefore we can have a different (and a 
smaller) epilog code at each exit point. The second exit point, e2, may be split into 
two again, optimizing the epilog code further. The procedure in Fig. 1(a) will execute 
4 h- 4 register saving/restoring operations, while that in Fig. 1(b) will execute 4 h- 2 reg- 
ister saving/restoring operations regardless of which exit point it takes. 




(a) 




e1 : restore r28, r30 e2: 

exit procedure 



restore r29, r31 
exit procedure 



Fig. 1. Applying epilog tailoring technique on a procedure 
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Other efforts to optimize prolog/epilog of procedures have been reported in 
[5,6,7,10]. In [5], Huang investigates the reuse of output results of some basic blocks 
during the run time when the same input values to them are detected. Not all basic 
blocks are reusable, because the input values are rarely identical for different execu- 
tions of the basic blocks. But a prolog basic block is a good candidate for such reusing 
technique, because a procedure is often called with the same parameters. In [6,7,10], 
the output reusing is reduced to a single instruction. Prolog and epilog again provide a 
good source of instructions for such technique. Both cases do not reduce the absolute 
number of prolog/epilog instructions as in our case. 



3. Prolog Tailoring 

The basic idea of prolog tailoring is to push down the location of the register-saving 
operations along the execution paths as close as possible to the point where the regis- 
ters are actually killed. Fig. 2 shows how prolog codes are generated on the same code 
as in Fig. 1(b). It saves only 2 registers at all entrance points, while the code in Fig. 
1(b) saves 4. As the result, regardless of which path the procedure takes in the run 
time, the code in Fig. 1(b) expends 6 operations in register saving/restoring, while the 
code in Fig. 2 expends 4 operations. 




Fig. 2. Applying prolog tailoring technique on an epilog tailored procedure 

One important question in prolog tailoring is how far we can push down the regis- 
ter-saving operations. If a basic block is killing register rl, the saving operation for rl 
can be pushed down to the entrance point of the basic block. If a register is killed in 
several basic blocks that have a common parent node, its corresponding saving opera- 
tion can move down to the entrance point of the basic block where the parent node 
belongs to. Moving it further down will cause duplication of register-saving opera- 
tions. If a register is killed inside a loop, the corresponding saving operation should be 
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stopped before the loop. Once entering the loop, the register-saving operation will be 
executed repeatedly, wasting the CPU time. Finally, if a register is killed inside a 
diamond structure, e.g. if-then-else structure, the corresponding saving operation 
should be located before the structure, unless the join point of this diamond is split. 




Fig. 3. Register-saving code generated inside a diamond structure 

Pushing register-saving operations inside a diamond structure may modify the se- 
mantics of the original code. Fig. 3 shows an example. In the figure, we have pushed 
down the register-saving operations into a diamond structure to make them closer to 
the destruction points. The path reaching L3 kills only r28, while the path reaching L4 
kills r28 and r30. Therefore, the code in Fig. 3 saves r28 on L3 path and r28 and r30 
on L4 path. However, at exit 1, the jointing point of L3 and L4 path, r28 and r30 both 
are restored. If the program took L3 path during the run time, we are saving r28 only 
and restoring r28 and r30. Since the stack frame does not contain the original value of 
r30, the final value restored in r30 becomes unpredictable. 

In this paper, we propose algorithms to push down register-saving operations as 
close as possible to the actual destruction points but not with unnecessary duplication 
nor with incorrect modification of the original program’s semantics. 



4. Prolog Tailoring Algorithm 

We assume a control glow graph is already built for a procedure for which we want to 
add prolog and epilog. Further, we assume the epilog is already tailored as explained 
in Section 2. The first step to tailor the prolog is to detect diamond and loop structures 
and replace them with a single node. With this replacement, the control flow graph 
will become a tree. On this tree, we compute DKR (Definitely Killed Registers) at 
each node and determine which register should be saved where, based on these DKRs. 
The overall algorithm is in Fig. 4, and its major steps are explained in the following 
sections. 
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basicblockf g_t generate_prolog (basicblockf g_t bbfg) 

{ 

sccfg ^ remove loops from basic block flow graph; 
bccfg ^ remove diamond structures from sccfg; 
dkr ^ compute DKR (Definitely Killed Register) for each 
node in bccfg; 

tailored_bbf g ^ generate register-saving operations on 
bbfg based on dkr and bccfg; 
return tailored_bbf g ; 

} 



Fig. 4. Basic steps of prolog tailoring 



4.1 Removing Loops 

The first step of prolog tailoring is to remove loops. Loops can be identified as SCCs 
(Strongly Connected Components), and we can use Tarjan’s algorithm [9] to detect 
them. Fig. 5 shows how a loop is replaced with a single node in a control flow graph. 
Node 2, 3, and 4 in Fig. 4(a) form an SCC; they are replaced with a single node as in 
Fig. 4(b). All edges reaching node 2, 3, and 4 should also reach the new replaced 
node, and all leaving edges from them should also leave from the new node. The new 
graph with all loops removed is called an SCC flow graph. 





(a) (b) 




(c) 



Fig. 5. Constructing SCC flow graph and BCC flow graph 



4.2 Removing Diamond Structures 

The second step is to remove all diamond structures on the SCC flow graph. The 
modified graph is called a BCC flow graph. We can detect diamond structures by 
detecting BCCs (Bi-Conected Components) [1, 9]. To define a BCC, let’s define a bi- 
connected graph and an articulation point as in [1]. An articulation point is a node in a 
graph that divides the graph into two or more sub-graphs when it is removed. A bi- 
connected graph is one that does not have any articulation point. A BCC is a hi- 
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connected sub-graph inside a full graph. Node {2,3,4}, 6, and 7 in Fig. 5(b) form a 
BCC; therefore they form a diamond structure. By replacing them with a single node, 
we get Fig. 5(c). 

The BCCs detected by Tarjan’s algorithm may contain shared nodes, nodes con- 
tained in more than one BCC. We need a systematic way to decide the membership of 
such a shared node. 



Table 1. BCC set found in Fig. 5(b) 



BCC 


1 


2 


3 


4 


SCC 


1, (2, 3,4} 


1,5 


(2, 3, 4}, 6, 7 


6, 8 



Table 1 shows the four BCCs found in Fig. 5 by Tarjan’s algorithm. In the table, 
node 6 belongs to BCC node 3 and 4; therefore it is a shared node. The algorithm to 
remove shared nodes is in Fig. 6. In the algorithm, a local root node of a BCC is an 
entrance node to that BCC. The overall algorithm to obtain a BCC flow graph from an 
see flow graph is in Fig. 7. 

bccset_t remove_shared_node (bccset_t bccset) 

{ 

for (ail BCCs in bccset) 

if (its local root nodes has outgoing edges from this BCC) 
remove this local root node; 
for (all BCCs in bccset) 

if (there is a shared node) { 

remove the shared node in the parent BCC; 
if (the parent BCC becomes empty) 

remove the parent bcc from bccset; 

] 

if (the root of scefg was removed ) { 

generate a BCC that includes the root of scefg as the 
only member; 

add this BCC Into bccset; 

] 

return bccset ; 

} 



Fig. 6. Algorithm for shared node removal in a given BCC set 



bccfg_t scc_to_bcc ( seef g_t scefg) 

{ 

bccset ^ detect all BCCs from scefg; 
bccset ^ remove_shared_node (bccset ) ; 

beefg ^ add links among BCCs in bccset based on the edges 
in scefg; 

return beefg ; 

} 



Fig. 7. Algorithm for constructing a BCC flow graph from a given SCC flow graph 
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4.3 Computing DKRs 

The third step is to compute killed registers at each node in the BCC flow graph and 
to compute DKRs based on them. A DKR of a BCC node represents a set of registers 
that are definitely killed in all paths starting from this BCC node. Fig. 8 shows a BCC 
flow graph with killed-registers and a DKR at each node. For example, at node 1, we 
can see r27 is killed inside node 1, and r28 is killed at both paths starting from node 1; 
therefore the DKR for node 1 includes r27 and r28. The DKR of node n can be de- 
fined recursively as follows. 

DKR(n)= ^DKR(j) + killed _reg(n) 

for j€child{n) 




Fig. 8. Computing DKR of each node and generating register-saving instructions 



4.4 Prolog Generation 

The last step is to generate register-saving operations. We start from the root node in 
the BCC flow graph moving down. At each node visited, we generate prolog for the 
registers belonging to its DKR except for the registers that are saved already. Fig. 8 
shows prolog codes generated at each node. For example, at node 1, all registers in 
the corresponding DKR, r27 and r28, are saved. At node 2, the DKR contains r28 
which is already saved 

If we have to insert register-saving operations inside an SCC, we need an extra step 
as in Fig. 9. Fig. 9(a) shows a BCC node that includes node 5, 6, and 7. We assume 
that node 5 is by itself an SCC, and that it is the entry point of this BCC. Fig. 9(b) 
shows how node 5 looks like. When the algorithm decides that a prolog has to be 
generated at this BCC, the actual register-saving operations are generated on the entry 
node of it, which is node 5. Since node 5 is an SCC, the operations are generated on 
the starting basic block of this SCC, which currently includes only vl as shown in 
Fig. 9(b). After inserting the register-saving operations, the flow graph becomes 
Fig. 9(c). Now the problem is clear; the register-saving operations are inside a loop. 
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We need to adjust the targets of node v30 and v40, the children of vl, so that the 
prolog is hoisted out of the loop. The overall prolog generation algorithm is in 
Fig. 10. 



5. Experiments 

To measure the performance of our prolog tailoring algorithm, we took 8 procedures 
from xlisp 2.1, performed prolog tailoring on them, counted how many register-saving 
operations are generated, and finally computed the reduction rates compared to the 
numbers without prolog tailoring. Assuming all paths are selected equally, the average 
number of register-saving operations per path can be computed as follows. 




(c) Node 5 after register-saving opera- (d) Node 5 after adjusting back edges 

tions inserted 



Fig. 9. Generating register-saving operations inside an SCC node 
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insert_regsave_code(node_t *n, regset_t tosave) 

{ 

generate register- saving operations for registers in “tosave” in the beginning of “n”\ 
if( “n” is an SCC byitself) ( 
old_start 4- the location after the generated operations', 
for( all branching operations in “n ” ) 
if( branching to “n ” ) 
adjust to branch to old_starf, 

) 

) 



insert proloq (bfqnode t *n) 

{ 

if (there are registers in DKR(n) that are not saved yet) 

{ 

V ^ the registers in DKR(n) that are not saved yet; 
for ( all local root nodes of "n" , k ) 
insert_regsave_code (k, v) ; 

} 

for( all children of "n" , j) 
insert_prolog ( j ) ; 

} 



Fig. 10. Algorithm for generating register-saving instructions 

In above, PT is the number of executable paths; NE, the number of exit points; NSj, 
the number of register-saving operations on a path ending with exit point /; PEj, the 
number of possible paths reaching to exit point /; and finally, AS, the average number 
of register-saving operations. 

The result in Table 2 shows that the average reduction rate is 17.4%. Excluding the 
most and the least reduction rates, it is 12.82%. 



Table 2. The decreased number of register save instructions by prolog tailoring 



procedure 


Before tailoring 


After tailoring 


difference 


Reduction rate(%) 


placeform 


7 


4.51 


2.49 


35.57 


mark 


8 


5.50 


2.50 


31.25 


sweep 


9 


6.50 


2.50 


27.78 


xlpatprop 


5 


4.00 


1.00 


20.00 


evlist 


9 


7.50 


1.50 


16.67 


xlenter 


6 


5.79 


0.21 


3.50 


evalh 


9 


8.70 


0.30 


3.33 


cons 


9 


8.85 


0.15 


1.67 


average 








17.47 


Normalized 

average 








12.82 
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6. Conclusion 

In this paper, we have proposed a prolog tailoring technique to reduce the overhead of 
prolog code in a procedure. Our algorithm generates register-saving operations as 
close as possible to the actual destruction points of the corresponding registers, but 
without unnecessary duplication and without incorrect modification of the original 
program’s semantics. To achieve this, the proposed algorithm transforms the given 
control flow graph of a procedure into a BCC flow graph, compute DKRs on it, and 
generates prolog code. Through experimentations, we have observed that our method 
reduces the number of register-saving operations by 12.82% in average. 
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Appendix A. An Example 

To show how the prolog tailoring algorithm is working, we took an example proce- 
dure from the source code of xlisp 2.1: placeform() in xlcont.c. Fig. A(a) shows the 
basic block control flow graph of this procedure. The graph is obtained from the as- 
sembly code produced by the IBM RS/6000 xlc compiler; therefore it is already epi- 
log-tailored. Node 1 is the entrance point, and node 20, 29, 34, 42, 48, and 50 are the 
split exit points. 
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Fig. A. Control flow graph of placeform 

A.l. Removing loops to generate an SCC flow graph 
Tarjan’s algorithm is applied to detect and remove SCCs. Node 10, 11, 12, 13, 14, 
and 15 form an SCC: they are replaced with a single node as in Fig. A(b). The in- 
coming to and outgoing edges from these nodes are adjusted accordingly. 

A.2. Removing diamond structures to generate a BCC flow graph 
The next step is to remove diamond structures. Tarjan’s BCC detection algorithm is 
used to find out all BCCs. Those nodes shared by more than one BCC are removed by 
the algorithm in Fig. 6. Table A1 shows the process of removing shared nodes. The 
second column in the table shows the BCCs detected by Tarjan’s algorithm. The bold- 
faced nodes are the entry nodes (or local root nodes) in each BCC. 

To remove shared nodes, we apply the algorithm in Fig. 6. First step is to remove 
all local root nodes that have outgoing edges from the current BCC. The local root 
nodes of BCC b2, b3, b6, b7, bl3, bl4, bl5, bl6, and bl8 have outgoing edges; thus 
removed. After this removal, we search for shared nodes. The one in the preceding 
BCC node will be removed. Node 2 in b2, node 49 in b3, node 4 in b6, node 44 in b7, 
node 46 in b8, node 36 in blO, node 41 in bl 1, node 33 in bl6, node 26 in 18, node 28 
in bl9, and finally node 19 in b21 are thus all removed. Lastly, node 1, the root of the 
SCC flow graph, does not exist in the final BCC set; therefore, we generate a BCC 
with node 1 as the only member and make it the root of the BCC flow graph, too. The 
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third column in Table Al shows the final BCC set. After adding proper edges, the 
final BCC flow graph is built as in Fig. B. 



Table Al. Differences between before and after removing shared nodes 



BCC# 


BCCs 


BCCs after removing shared nodes 


bl 




1 


b2 


1,2 


- 


b3 


1,49 


- 


b4 


49, 50 


49, 50 


b5 


2,3 


2,3 


b6 


3,4 


- 


b7 


3,44 


- 


b8 


44, 45, 46, 47 


44, 45, 47 


b9 


46, 48 


46, 48 


blO 


4, 5, 43, 35, 36 


4, 5, 35, 43 


bll 


36, 37, 38, 39, 40, 41 


36, 37, 38, 39, 40 


bl2 


41, 42 


41, 42 


bl3 


5,6 


6 


bl4 


6,7 


- 


bl5 


6, 25 


25 


bl6 


25, 33 


- 


bl7 


33, 34 


33, 34 


bl8 


25, 26 


- 


bl9 


26, 27, 28, 30,31,32 


26, 27, 30,31,32 


b20 


28, 29 


28, 29 


b21 


7 ... 19,21 ... 24 


7 ... 18,21 ... 24 


b22 


19, 20 


19, 20 



A. 3 Computing DKRs and generating register-saving operations 
Killed-registers are computed for the BCC flow graph as in Table A2. They are 
shown in the second column in Table A2. Based on the formula in Section 4.3, DKRs 
are computed as shown in the third column of Table A2. With these DKRs, we can 
determine where to save which registers as in the fourth column of the table. 



Table A2. Killed registers and DKR 



BCC# 


Killed registers 


DKR 


Registers to be saved 


bl 


r28,r29,r31,lr 


r28,r29,r31,lr 


r28, r29, r31,lr 


b4 


r30,r31,lr 


r30,r31,lr 


r30 


b5 


r31 


r31,lr 


- 


b8 


r30,r31,lr 


r30,r31,lr 


r30 


b9 


- 


- 


- 


blO 


- 


Ir 


- 


bll 


r30, Ir 


r30, Ir 


R30 


bl2 


- 


- 


- 


bl3 


- 


Ir 


- 


bl5 


- 


Ir 


- 


bl7 


Ir 


Ir 


- 


bl9 


r27,r28,r29, r30,r31,cr4, 
Ir 


r27, r28, r29, r30, r31, cr4, 
Ir 


r27, r30, cr4 


b20 


- 


- 


- 


b21 


Ir 


Ir 


- 


b22 


- 


- 


- 
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Abstract. Hierarchical Constraint Satisfaction Problems (HCSPs) are 
at the centre of attention in the fields of computer aided design and user 
interfaces. Till recently, the algorithms proposed to solve the problems of 
this class focused only on its small subclasses (like problems with acyclic 
constraint graph or linear systems). Here we present a new family of 
hierarchical constraint satisfaction algorithms based on the mechanism 
of subdefinite models. The main advantage of the proposed algorithms 
is their applicability to a broad class of problems, including cyclic and 
non-linear ones. 



1 Preliminaries 

The mechanism of subdefinite models was proposed by the Russian scientist 
Alexander Narin’yani at the beginning of 1980s |T| independently on the western 
works in the field of constraint satisfaction problems (CSPs) [^. Today we can 
say that this mechanism is a general-purpose apparatus to deal with CSPs. 
Using it, we have no restrictions on the domain of variables (taking into account 
both finite and continuous ones), the nature of constraints (dealing with both 
binary and n-ary constraints, implicit and explicit ones) . The modern description 
of the mechanism of subdefinite models as well as the proof of its correctness 
can be found in [5]. We use the well-known notion of many-sorted algebraic 
models to feel ourselves freely in discussing general properties of the algorithms 
under consideration (and thus to apply our results to a broad class of problems, 
including finite, continuous and mixed ones). 

With this chapter, we redefine the notion of HCSP (that was firstly proposed 
by Horning et al. 0) in many-sorted terms. 

1.1 Hierarchical Constraint Satisfaction Problem 

A many-sorted signature is a triple S = (S', F, P) where 

— S is a set of sorts (elements of S are names of different domains); we denote 
the set of all chains of elements of S (including an empty chain. A) by S*, 
i. e. S* = {A} U S U S^ U . . ., we also define S+ = S* \ {A}; 

— F is an (S* x S)-indexed family of sets of operators (function symbols) (i. e. 
F = {Fiu^s \ w £ S* , s G S}); F\^s is called the set of constants of sort s; 

D. Bj0rner, M. Broy, and A. Zamulin (Eds.): PSI 2001, LNCS 2244, pp. 434- 144^ 2001. 

(c) Springer-Verlag Berlin Heidelberg 2001 
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— P = {Pw \ w € S’+l is a family of predicate symbols containing the predicate 
symbol of equality, = G Pgs, for each sort s £ S. 

Let S = (S,F,P) be a many-sorted signature and X be an S'-sorted set (of 
variables) such that Xgi fl Xg/i = 0 for s' yf s" , and Xg fl F\^s = 0 for any s £ S. 
We define E{X)-terms as the smallest S'-indexed set Ts{X), such that 

— W, C Ts{X)s and Fx,s C Ts{X)s for all s G S; 

— if / G Fuj^s and U £ Ts{X)s- for w = si . . . G 5'+, then the string 
/(ti, . . . ,t„) belongs to Ts{X)g. 

We define a E{X)~ constraint c as an atom p{ti, . . . ,Pn), where p G -Psi...s„j 
ti £ Ts{X)s^ (i= 1, n). We denote the set of all variables occurring in constraint 
c by var(c). 

A Hierarchical Constraint Satisfaction Problem (HCSP) over signature E is 
a pair (X,C), where X is a set of variables, and C = {Co, Ci, . . . , Cm} is a 
family of finite sets of if(X)-constraints. A constraint c G Cq is called a required 
constraint, constraints from Ci U . . . U Cm are called non-required ones. 

1.2 Semantics 

For a many-sorted signature E = (S, F, P), a many-sorted E-model M is a, first- 
order structure consisting of 

— a family of carriers s^ for all s G S' (for w = si . . . s„ we denote the Cartesian 
product s^ X ... X by w^), 

— a family of functions f^ : — >■ s^ for all / G Fyj g, if w = A, then 

fM g 

— a family of predicates p^ C for all p £ P^, the predicate of equality 
=^C (ss)^ is {(a, a) I a G s^j for all s £ S. 

Let E = (S, F, P) be a many-sorted signature, X be an S-sorted set of variables, 
M be a A7-model. We call any S-sorted functiorli] 6 : X ^ M an estimate of 
variables X in A7-model M. The extension of the estimate 9 to the set Ts{X) is 
a function 9* : Te{X) — >• M defined as follows. For t G Ts{X)g, s £ S: 

{ 9g{x), A t = X for any x £ Xg, 

, if t = c for any c G F\,g, 

f^{9*g,ih ), . . . ,0,*„(t„)), if t = fih , . . . ,t„) for / G F^,g, 

W = Si . . .Sn £ S'^,ti £ Ts{X)g. . 

Let M be a A7-model. We will say that a constraint c = p(ti, . . . , C) holds in the 
model M iff there exists an estimate 6* : A — >■ M of the variables X in the model 

^ An S-sorted function 6 : X ^ M is actually a family of mappings 
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M, s. t. (0*^(ti), . . . G , where 9* : Ts{X) M is the extension 

of the estimate 9 to the set of I7(X)-terms. In this case we will also say that c 
holds on 9, or 9 satisfies c. 

Let M be a L'-model. For an HCSP P = {X, C) we define the set Sp^ of its 
basic solutions in the model M as follows: 

= {6» : X ^ M I (Vc G Co) c holds on 9}. 

The set of basic solutions thus is the set of all estimates, which satisfy the 
required constraints. For non-required constraints of level i > 0 we define the 
set as follows: 

= {9 ■. X ^ M \ (Vj = M(Vc G Cj) c holds on 9}. 

(Therefore, Sp^ 3 Sp-^ 2 2 Sp^.) Real-world HCSPs are often over- 

constrained. It means that often not only Sp^ = 0, but Sp^ can be empty 
too. Therefore, we need a theory to choose what basic solution does better sat- 
isfy non-required constraints. In other words, we need to compare basic solutions 
with respect to non-required constraints. A predicate better^ C SpQ x Spg is 
called a comparator if it has the following properties for any 9,4>,ip G S^q: 

1 . Irreflexivity: -ihetterp {9 , 9) 

2. Transitivity: better p {9, </>) A betterp {f, f) =k betterp {9, f>) 

3. Correctness: (Vi > 0) 0 G A ^ =k better;^ (0, f) 

The set of solutions of an HCSP P in a model M w. r. t. to a comparator better;^ 
is defined as follows: 

Sp, better^ = {6» G S'|fo I (V</> G 5')^o) -better((/>, 6») } . 



1.3 Types of Comparators 

We can classify some kinds of comparators. The simplest ones are so-called 
predicate comparators. Given a signature S, a L7-HCSP P = (A, C), a A- model 
M, and an estimate 9 : X ^ M, define H^f9) C C^ as a set of constraints 
from Cj, which hold on 9. Using these sets we can build two comparators: Ipb^ 
and gpb;^ (these names are acronyms for locally-predicate-better and globally- 
predicate-better): 



\ph^{9,(j)) 44> {3k > 0) 
gpb^{9,f)^{3k>0) 



(W=l,fc) 

A Hlf,{9) D Hif.if), 

A \H0^,{9)\ > iHif.if)]. 



The second group of comparators is metric ones. They are based on an error 
function. For an estimate 9 and a i7(A)-constraint c we define a non-negative 




Hierarchical Constraint Satisfaction Based on Subdefinite Models 



437 



real value e^{c,9), which is called the error of satisfaction of the constraint c 
on 9, and has the following property: e^{c,9) = 0 c holds on 9. Given , 
we define a comparator leb;^gM (an acronym for locally- error-better) as follows: 



leb^,M(6»,^) {3k > 0) 



(Vc G Cl U . . . U Ck) e^(c, 9) < e“(c, ({)) 
A (3cG Cfc) e^{c,9) < e"(c,0). 



Comparators from geb {globally-error-better) family take into account global 
information about errors on each level. They can be expressed using a global 
error g^M{Ci,9) = g{e^ ,Ci,9), which summarizes all the errors of constraints 
from Ci on the estimate 9: 



geb“M,,(0,<(.)4^(3fc>O) 



(Vz=l,/p) 9e!^{Ci,9) < g^M{C^,(|)) 



We will use two global error functions: wc (an acronym for worst-case), and Is 
{least-squares): 



wc(e^, Ci, 9) = maxe^(c, 9), 

cGCi 

ls{e^, Ci, 9) = ^ (e^(c,6»))2. 

ceCi 



We will use notations wcb^^M and Isb^gM for geb-comparators based on wc and 
Is functions respectively. 

Note, that predicate comparators can be unified with error ones by introduc- 
ing a special error function pe, called predicate error. 

M _ / 0: if c holds on 9, 

1, otherwise. 

Then Ipb and gpb comparators can be expressed via leb and Isb ones respec- 
tively. Therefore, it is sufficient to consider only three comparators: leb, web, 
and Isb. However, one can propose simpler algorithms for hierarchical constraint 
satisfaction based on predicate comparators rather than on error ones. 



1.4 A Simple Example 

Consider the following simple example of hierachical constraint satisfaction prob- 
lem. Imagine an end-user who draws and moves some figures on a screen, put 
positioning constraints on them, and a system which automatically redraws the 
figures on the screen according to user constraints. The user drew a point at 
position (0, 0) and put a required constraint that this point cannot be moved. 
Then he drew another point at position (100, 100) and put a strong constraint of 
distance between two these points: ’’the distance between them is not less than 
10” . Then he moves the second point to some position {x, y) on the screen. What 
is a possible reaction of the system? We can easily specify this problem as an 
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Fix, Var: Point2D; 
required: Fix.x = 0; Fix.y = 0; 
strong: Distance ( Fix, Var ) >=10; 

medium: Var.x = r; Var.y = y, 

weak: Var.x = 100; Var.y = 100; 



Fig. 1. Moving a Point HCSP 



HCSP. Here we have required constraints (the first point cannot be moved), and 
strong ones (distance constraint). We can model a point movement by medium 
constraints, and conservation of figures positions by weak constraints. Therefore, 
we deal with the HCSP presented in fig.lH 

Obviously, if the new coordinates of the point are outside the circle with 
radius 10 and center in (0,0), then the point will be moved there. Otherwise the 
system should firstly satisfy strong distance constraint, and then medium one. 
The possible positions of the point after movement and hierarchical constraint 
satisfaction are presented in fig. 




Fig. 2. Possible solutions of Moving a Point HCSP 
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Locally-error-better solution is produced by satisfying constraints in turn 
(firstly positioning x coordinate, then j/, or vice versa). Since after satisfying 
one of these constraints we cannot satisfy another one, the weak constraints (old 
coordinates) is used for positioning the point on the second coordinate. 

Globally-error-better solution is obtained in other way (we try to satisfy as 
many medium constraints as possible), but it is the same as locally-error-better 
one, since we cannot satisfy both coordinate constraints simultaneously. 

Searching locally-error-better solution, the system tries to minimize an error 
of a constraint satisfaction. In our case, this error equals the difference between 
real and desired coordinate. A solution to be produced depends on the order of 
considering constraints (firstly positioning x coordinate, then y, or vice versa). 

Worst-case-better solution is a positioning which minimizes the maximal de- 
viation of one of coordinates from desired value. Semantics of the solution can 
be expressed by the square of minimal size with center in (x,y), which contacts 
with the big circle. The point of contact is a solution. 

Similarly, least-squares-better solution can be expressed by the circle of min- 
imal size with center in {x,y), which contacts with the original circle. 

2 Subdefinite Models 

The algorithms of hierarchical constraint satisfaction, discussed below, are im- 
plemented in subdefinite models framework. Before considering the algorithms, 
we briefly remind the basic concepts of subdefinite models. 



2.1 Subdefinite Extensions 

In we have shown that subdefinite model approach allows one to find an 
approximation of the set of all solutions of a CSP (in terminology of this paper, 
to find an approximation of the set of all basic solutions of an HCSP). This 
approximation is done by the means of achieving local subdefinite consistency. 
First, we build subdefinite extensions {SD- extensions) of universes (carriers) of 
given A-model. If 17 is a universe, then its subdefinite extension, *U is a set of 
subsets of U, satisfying the following properties: 

1. {0,C/} C *U. 

2 . {vv,w €*u)vnw €*u. 

3. There are no infinite decreasing chains (P D IT D . . .) in *U. 

Any subset V of U can be approximated in SD-extension *U as follows: 




W. 



( 1 ) 



VQWe*u 
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Let X be an ^'-sorted set of variables, M be a if-model, and *M be its 
SD-extensior0. A suhdefinite estimate (SD-estimate) is an ^-sorted mapping 

e = {e, : X, ^ I s e 5}, 

which maps each x G Xg (s G S) into a suhdefinite value 0{x) G *s^ . An 
SD-estimate 0 is narrower than another SD-estimate ^ iff 0{x) C <P(x) for all 
X G Xg, s G S. An estimate 9 is contained in an SD-estimate 0 (writing 9 G 0) 
iff 9{x) G 0{x) for all x G Xg, s G S. An SD-estimate, which does not contain 
any estimate, is called an empty SD-estimate (writing 0 = 0). 

Given a signature S, and an 5-sorted set of variables X, let c be a A- 
constraint, M be a A-model, and *M be its SD-extension. A filtering of the 
constraint c is a mapping on the set of SD-estimates, satisfying the following 
conditions for any SD-estimates 0, 

1. Contraetness: Tc{0) Q 0- 

2. Monotonicity: 0 C ^ .Ac(0) C TcfiP). 

3. Correctness: if c holds on 9, then 9 G 0 ^ 9 G J-c{0)- 

4. Idempotency: lFc{iFc{0)) = Tc{0)- 

An SD-estimate 0 is consistent w. r. t. a constraint c iff J-c{0) = 0- It is easy to 
see, that for any set C of constraints there exists unique SD-estimate 0^ s. t.: 

1. 0Q is consistent w. r. t. each c G C. 

2. If an SD-estimate <P is consistent w. r. t. each c G C, then <l> C 0f,. 

Moreover, if there exists an estimate 9 s. t. each c G C holds on 9, then 9 G 0q. 
Therefore, 0f, is an approximation of the set of all the estimates which satify 
any c G C. For an HCSP {X, {0i, . . . , Cm}), 0Cg is an approximation of the set 
of its basic solutions. 

Fig. El shows the algorithm of finding the maximal consistent SD-estimate for 
a given set of constraints C. It uses a global structure Ass, where Ass(x) is a set 
of constraints from C where the variable x occurs. The function returns False if 
the inconsistency is detected during filtering (it means 0fi = 0). Choosing c in Q 
(the fourth line) can be arbitrary, but we use the principle ’’first in — first out”, 
i. .e. regard Q as a queue. In we have proved that the call Revise(0°, 0), 
where 0'^(a:) = s^^ for any x G Xg, s G S always produces 0fi. 

2.2 Solving an HCSP 

We deal with a signature A = {S, F, P), where there is a sort real G S, and all 
constant, functional, and predicate symbols on it. We also deal with a A-model 
M, where real^ is the set of all real numbers, and all functional and predicate 
symbols have traditional interpretation (”-!-” as addition, ”=” as equality, etc.) 

^ For the purpose of this paper we define an SD-extension of a A-model Af as a set 
of SD-extensions of its carriers {*s^ \ s £ S}. Here we deal no with SD-extensions 
of functions and predicates. 
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function Revise( in out 0, in Q ) : boolean 
begin 

while Q 7 ^ 0 do 
choose c € Q; 

for X £ var(c) do 
if &{x) 7 ^ ${x) then 

if 0{x) = 0 then return False end if; 
Q Qyj Ass{x) 
end if 
end for; 

Q ■(— Q \ {c}; 



O 

end while; 
retnrn True; 
end. 



Fig. 3. The algorithm for achieving the maximal consistency 



Suppose that all non-required constraints look like a; = 0, where x S real^, 
and Q £ with standard interpretation 0 as the real zero. (Below we 

consider the transformation of arbitrary HCSP to this form.) The need of globally 
processing all the constraints of the same level suggests us to deal with one 
constraint per level. Such a constraint has a form zero(a:i, . . . ,a:„) and is the 
reduction of a group of constraints {xi = 0, . . . , Xn = 0}. It is reasonable to use 
the same schema of calculations for all the types of comparators. This schema 
is presented in fig. [d] The call FilterNonRequiredConstraint stands for the 
one of the procedures of filtering presented in fig. FilterLPB, FilterGPB, 
FilterLEB, FilterWCB, or FilterLSB. Moreover, one can use different versions 
of comparators on each level of constraint hierarchy. 

Procedure FilterLPB has nothing special, but others use an internal stack to 
implement the depth-first search of the solution. If the inconsistency is detected 
in some branch, the procedure returns to the previous suspended branch. 

Procedure FilterLEB tries to narrow an SD-value of an argument variable 
as closer as possible to zero. However it has the following drawback. Suppose 
we have a non-required constraint x = Q and required one x = y — z. (In fact, 
it means we have a non-required constraint y = z.) Suppose there is no basic 
solution 0 with 0{x) = 0. When we try to narrow an SD-value of x to zero, 
we need to assign x with some value app^^^^^^M ({a}), where o > 0. Roughly 
speaking, it means we try to filter a constraint \y — z\ = a. This constraint has 
a disjunctive nature, since we do not know what constraint should be satisfied: 
y = z + a or z = y+a. This lack of knowledge is often the reason of poor filtering. 
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algorithm SolveHCSP( in P = {X, {Co, {ci}, . . . , {cm}}), out O ) 

begin 

[ build structure Ass ]; 
for s G S', a; € Xs do 

0(x) t— ’/. assigning the maximal undefined values 

end for; 

if not Revise(C,Co) then 
0^0 
else 

for i = 1, . . . , m do 

FilterNonRequiredConstraint(0, d) 
end for 
end if 
end. 



Fig. 4. The general algorithm for solving an HCSP 



The FilterWCB and FilterLSB procedures differ only in the function g(6>): 
ffwcb(^) = n§-xsup6)(a;i), 

n 

5lsb(^) = 

i=l 

One can note that our algorithms are not complete in general sense: we cannot 
guarantee the existence of a solution in resulted subdefinite values. However, in 
real-world problems we can easily add weakest non-required constraints x = 
(with arbitrary chosen a^) for all the variables of an HCSP under consideration, 
and thus the resulted values will be defined. 

2.3 Transformation of an HCSP to a Simple Form 

Remember, all the algorithms above deal with an HCSP, where all non-required 
constraints look like a; = 0 for real variable x. How to transform any HCSP to 
this form? First, we need to extend our signature S = (S', F, P) with a functional 
symbol diff^ for each sort s G S: diff^ G . This symbol should have the 

following interpretation in a X-model M: diff^(a, 6) = 0 a = 6. For example, 
diffreal can be implemented as diff^^^(a, 6) = |a — 6|. 

Consider a constraint p(ti,...,t„) G Ck {k > 0), where p is a predicate 
symbol, and U G Tj;(X)s^ (i = l,n) are terms. Let t6i , . . . ,Un be new variables 
of sorts si, . . . , s„ respectively, and vi, . . . ,v„he new variables of sort real. Then 
we transform our constraint into a set of ones: 

— required constraint p{ui, . . . ,Un), 

— required constraints diffs^(ui,ti) = Vi for i = l,n, 

— non-required constraints Ui = 0 for i= l,n. 
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procedure FilterLPB( in out 0, in c = zero(a;i, . . . ,Xn) ) 
begin 

for i = 1,11 do 
if 0 G 0{xi) then 

<P{xi) ^ app^g^jM({0}); 

if Revise(^, Ass(a:i)) then 0 ^ $ end if 

end if 
end for 
end. 

procedure FilterGPB( in out 0, in c = zero(a;i, . . . ,Xn) ) 
begin 

0* ^ 0; fc* ^ 0; 
pnsh(0, 1, 0); 

while non-empty-stack do 

pop(0,i,fc); 

if i > n then if fc > fc* then 0* <— 0; k* <— k end if 
else if 0 G 0(xi) then 
push(0, i + 1, fc); 

0{xi) ^ app.j,gg^jM({0}); 

if Revise(0, Ass{xi)) then pnsh(0, i + 1, fc + 1) end if 

end if end if 
end while; 

0^0* 

end. 

procedure FilterLEB( in out 0, in c = zero(a;i, . . . ,Xn) ) 
begin 
i ^ — 1; 

while i < n do 

push(0, i); 

0{xi) t- app.j.gg^jM({inf |0(a;i)|}); 

if not Revise(0, Ass(a:i)) then pop(0,i); end if 

i t— i + 1 

end while 
end. 

procedure FilterWCB/LSB( in out 0, in c = zero(a:i, . . . , ®„) ) 
begin 
w* <— 0; 
repeat 
w 5(0); 
push(0^^); 

for i = l,n do 0{xi) t— 0{xi) D [— ™ ™ end for 

if not Revise(0, U^^j^Ass(a;i)) then pop(0,tn*); end if 
until w — w* < e "/, precision of calculation 
end. 



Fig. 5. The procedures of filtering better solution 
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2.4 Implementation Issues 

These algorithms have been implemented in the framework of constraint pro- 
gramming environment NeMo+ [S|- Table [I] presents CPU time measured on 
AMD Athlon 1.1 GHz Windows NT Workstation when solving two HCSPs on 
different input data. Point (.x,y) denotes Moving a Point HCSP considered 



A, B, C: 


Point2D; 








required: 


: Angle ( A, 


c, 


B 


) = Pi/2; 


strong: 


Distance ( 


B, 


C 


) <= DistanceC A, C 


medium: 


Distance ( 


B, 


C 


) = X-, 




Distance ( 


A, 


C 


) = y, 




Distance ( 


A, 


B 


) = t; 


weak: 


// constraints 


on coordinates. . . 



); 



Fig. 6. Right Triangle HCSP 



in section 11.41 (where x and y are coordinates of new position for the point), 
while Triangle (x,y,z) denotes an HCSP presented in fig. [H Note, we have 
not found Isb-solution of some problems in reasonable time (the corresponding 
times are marked with ’?’ sign in the table. 

Our experiments suggest the following recommendations of using the pro- 
posed algorithms for solving HCSPs. First of all, we want to emphasize the min- 
imal complexity of searching two kinds of solutions: locally-predicate-better and 
locally-error-better. We cannot say this about globally-predicate-better, since it 
complexity must depend on the number of constraints in each level of constraint 
hierarchy. Our tests are very small to do such conclusion. 

The quality of worst-case-better solution suggests us to prefer it to ones 
discussed above, but we see, that its complexity is more greater. On the other 
hand, we see, that its complexity does not depend drastically on input data, and 
it can be small enough (less than one second for our test problems). We believe, 
there can exist problems, where getting this type of solution is preferable. 

Discussing least-square-better solution, we need to say, that this type of so- 
lution having the best quality from all the types, however, requires a number of 
system resources. (In our tests, we have not obtained this solution in reasonable 
time for some set of input data.) But for other sets of input data its complexity is 
small enough. In any case, this type of hierarchical constraint satisfaction should 
be used carefully. 

3 Related Works 

There are a number of algorithms for solving an HCSP. Most of them find a 
locally-predicate-better solution. Among others, the two most similar to our ones 



Hierarchical Constraint Satisfaction Based on Subdefinite Models 



445 



Table 1. Performance results of solution search for different HCSPs 



Problem 


Ipb-time 


gpb-time 


leb-time 


wcb-time 


Isb-time 


Point (-6,8) 


0 


0 


40 


400 


30 


Point (-4,-4) 


0 


0 


40 


410 


2894 


Point (-3,1) 


0 


0 


40 


390 


3204 


Point (2,0) 


0 


0 


40 


400 


390 


Point (0,0) 


0 


0 


40 


390 


? 


Triangle (3,4,5) 


10 


30 


200 


540 


110 


Triangle (4,3,6) 


10 


30 


200 


570 


4005 


Triangle (4,3,5) 


10 


20 


200 


530 


2052 


Triangle (4,3,4) 


10 


20 


200 


550 


4286 


Triangle (4,3,2) 


10 


10 


200 


580 


7 



are Indigo [3 and Projection [8]. They are both intended for searching a locally- 
error-better solution and deal with interval values of variables. Indigo processes 
acyclic constraint graphs with numerical constraints and has the polynomial 
complexity. Projection processes systems of linear equations and inequalities but 
takes exponential time in the worst case. Of course, our general-purpose algo- 
rithm is not so efficient as these two, but it can be applied to non-linear systems 
with cyclic constraint graph: this is its main advantage. 

Acknowledgements. The author is indebted to anonymous referees for their 
valuable comments. 
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Abstract. We discuss different possibilities of using the Constraint Pro- 
gramming Solvers (CPS) in CAD/CAM systems. The NeMo+ CPS, 
based on the approach of Subdefinite Models (SD-Models), and some 
its specializations are considered. The paper presents some components 
of a CAD/CAM system, where the NeMo+ solver is used or can be used, 
discusses the advantages of this approach. 



Introduction 

Constraints are one of fundamental things that is intuitively known for the user 
in all areas of activity, including the CAD/CAM one [1]. Generally speaking, 
each interaction of two variables can be considered as a constraint. Constraints 
allow the user to specify the problem in the declarative manner. He doesn’t need 
to specify ”HOW to solve the problem”, but only ’’WHAT a problem is necessary 
to solve” . 

Obviously, it is very important HOW constraints are solved. For solving the 
constraint satisfaction problem in the CAD/CAM system we propose to use 
the object-oriented solver NeMo+ [2, 3]. It is based on the well-known sub- 
definite models (SD-models) approach, proposed in the early 80th by Dr. A.S. 
Narin’yani [4], and founded in [5, 6]. 

We consider that the model of the designed entity (i.e. the designed product) 
in a CAD/CAM system consists of the physical part and the functional one. 

The physical model is a decomposition of the product in assemblies, parts 
and design features. An assembly is a set of parts and or assemblies, the model 
can contain as many assembly levels as needed, a part is a set of features and a 
feature is a set of parameters that determine its properties and its behavior. 

The functional model is a decomposition of the product in the different func- 
tions that it has to support. The product is divided into functions, the model can 
contain as many function levels as needed. Each elementary function (a function 
that can not be further decomposed) is implemented in the solver. A function 
can include features coming from different parts. The functional model allows 
the designer to work directly with functions, not necessarily knowing which parts 
are involved. 

In this paper we propose an approach of a Constraint-Based CAD/CAM 
system, which, in our view, will have the following advantages: 
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— the designer has the possibility to work with the approximately known (or 
subdefinite) values of parameters (e.g. intervals - for real numbers, enumer- 
ations for discrete values, etc.); 

— the solver returns to the designer both the validated subdefinite values, which 
can be more definite than the initial ones, and one of the exact solutions; 

— the solver is able to solve together both the geometric constraints and the 
engineering ones. Thus it can considerably reduce the number of backtracks 
in the design process; 

— the subdefinite model can be used all along the development of a design 
application since it can support the design knowledge acquisition, the imple- 
mentation and the maintenance phases. 

The paper is organized as follows. Section 1 gives a brief description of the 
constraint programming environment NeMo+. In section 2 we present a NeMo+ 
specialization for solving the geometric problems. The possibilities of using the 
constraint solver in conceptual and assembly design is discussed in section 3. The 
use of NeMo+ in Knowledge component of a CAD/CAM system is presented 
in section 4. Section 5 gives a brief description of the use of NeMo+ for solving 
time-based problems in digital manufacturing and product data management. 
The last section contains the conclusions and further plans. 



1 NeMo+ Constraint Programming Environment 

The object-oriented constraint programming environment NeMo+ is a state- 
of-the-art constraint solver that, besides the traditional constraint satisfaction 
algorithm, incorporates a number of constraint programming techniques: root 
locating, symbolic transformations and differentiation, heuristics for partial sat- 
isfaction problems, specialized module for solving geometric constraints. 

The standard NeMo+ environment has the following peculiarities: 

1. An extended set of predefined data types which may have finite as well as 
infinite domains of values. It includes an extensive library of basic (i.e. imple- 
mented in C-|— k) constraints for such data types as set. Boolean, integer and real, 
strings, and any other types defined by the user. The domain of a variable can 
be represented by a single value, by enumeration of possible values, by interval 
or multi-interval values. The choosing of data type representations allows the 
user to the compromise between the solution quality and the calculation time. 
For more details on data types in SD-models see [7, 8]. 

2. Availability of high-level facilities for specification of problem-oriented 
constraints and data types. It includes a high-level language for specification 
of systems of constraints. This language is a purely declarative one and allows 
the user to describe a system of constraints as a collection of formulas. Object- 
oriented properties of the NeMo+ language are used to define the structure of a 
model and to define problem-oriented data types and constraints from the base 
ones. In addition, the language includes sophisticated means for controlling the 
constraint propagation process. 
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3. Solving the direct and the inverse problems on the same specification of 
the problem. Taking into account the initial values or parameters, the solver 
defines itself what problem should be solved (direct, inverse, or both). 

4. Use of the method of subdefinite models to satisfy the system of con- 
straints. The main feature of the method of SD-models is that it uses a single 
algorithm of constraint propagation to process data of different types. This al- 
lows one to solve mixed of constraints including simultaneously set. Boolean, 
integer and real variables and constraints on them. Moreover, NeMo+ proposes 
different techniques to find an exact solution, including the optimal one. 

5. NeMo+ can process constraints defined by tables, including database ones. 
It chooses all reliable data from the table/database and uses them in another 
constraints as subdefinite data. It should be mentioned that tables/databases 
themselves may contain the subdefinite values [9]. 

The algorithm of computations implemented in SD-models is a highly par- 
allel data-driven process [5]. Modification of the values of some variables in the 
common memory automatically results in calling and executing those constraints 
for which these variables are arguments. The process halts when the execution 
of constraints does not change the variables values. 

Consider now an example that illustrates this algorithm. Suppose that we 
need to solve the following system of two linear equations: 
y = x-l; (FI) 

2*y = 3*{2-x); (F2) 

Each equation may be regarded as an implicit function (FI and F2) of two 
variables x and y. The plots of these functions are shown in Fig. 1 a). 

Suppose that an initial approximation to the variable x is known: between 
— 1 and 4 (this estimate can be represented by the interval [—1, 4]). The idea 
of subdefinite computations is to use the current estimate to compute in turn 
the projections of the functions FI and F2 onto x and y. For instance, the 
projection of FI onto y for x equal to [—1, 4] is the interval [—2, 3]. The result 
of the projection is shown in Fig. 1 b). 

If we now use y to compute the projection of F2 onto x, then we will obtain 
a new value of x equal to the interval [0, 10/3] (see Fig. 1 c). Continuing the 
process, we will gradually approach the desired solution. Fig. 1 d) shows two 
spirals demonstrating how we approach the solution from below and from above, 
respectively. 

It is worth noting that the parameters of real problems always have initial 
approximations of their values. Even if the person solving a problem cannot 
determine the initial constraints on the domain of some numerical parameter its 
subdefinite value will be estimated by the interval from minus infinity to plus 
infinity. 

During the computation of one model, the solver starts twice. At first, it 
checks the consistency of the model and improves the initial subdefinite values. 
Then, it starts for finding one of the exact solutions. Both results, the subdefi- 
nite (consistent) values and the exact solution are persistent in the CAD/CAM 
system. 
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c) d) 



Fig. 1. Illustration of the algorithm of subdefinite computations 



The NeMo+ solver has been implemented jointly by Russian Research In- 
stitute of Artificial Intelligence (Moscow-Novosibirsk) and by Institute of Infor- 
matics Systems (Novosibirsk). 

Summarizing all these properties we can say that NeMo+ can be used in 
different parts of CAD/CAM systems such as: 

— Sketcher (geometric solver); 

— Conceptual and assembly design; 

— Knowledge based engineering; 

— Digital manufacturing and product data management. 

Moreover, NeMo+ can be placed in the kernel of a CAD/CAM system (so-called 
feature platform) to provide a general-purpose solution for both update engine 
and user interaction. 
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2 Constraint Solver for Geometric Modeler 

Geometric applications in CAD/CAM area all have a fundamental requirement 
to maximize the productivity of the designer by enabling the efficient construc- 
tion and modification of geometric models. 

In our view, each geometric problem belongs to the class of constraint satis- 
faction problems, i.e. its specification is a declarative one, which contains a set 
of objects connected by a set of geometric constraints. 

Present CAD systems are merely based on parametric or variational design. 
The best known of geometric solvers is DCM (Dimensional Constraint Manager 
by D-Cubed Ltd.) [10] . DCM is based on an algorithm for computing the solution 
for a subset of all possible equations of geometry and dimensions, using purely 
algebraic methods. The usual arithmetic operations are used including square 
roots. DCM considers in detail the equations that are obtained when points, 
lines and circles on a plane are defined by means of relative distance and angle 
constraints. The main result is that these equations can be solved algebraically 
for a significant class of configurations. 

In [11] the DCM method is seen as a propagational solver; solving con- 
straints that can sequentially be constructed on a drawing board, using ruler 
and compass. According to [11] propagational solvers offer robustness, accu- 
racy and speed. However, they are restricted to relatively simple problems. The 
main problem is that mathematical constraints which determine other product 
characteristics than those related to geometry alone also have to be taken into 
account [12]. These constraints cannot easily be solved in existing CAD systems 
as they are highly coupled and non-linear. The second problem is the problem 
of measurement accuracy, and tolerancing. It is almost evident that, due to the 
measuring instrument’s accuracy, some geometric values like lengths, distances 
and angles are approximately known in real-life problems. Different techniques 
can be used to solve such kind of problems. DCM is able to take into account the 
approximately known values of dimensions via inequalities, but it always returns 
only one exact solution. 

The main advantage of NeMo+ is that it is able to solve geometric problems 
with exact and/or interval values of parameters jointly with non-geometric (so- 
called, engineering) constraints, and it returns two kind of results: the exact 
solution, and the subdefinite values. 

For solving the geometric problems in the standard NeMo+ it is necessary 
either to specify all significant constraints (the theorem of cosine, the formulae of 
Heron, the sum of angles in the triangle, etc.) or to specify the problem in terms 
of high-level objects like triangles, rectangles, trapeze, etc, in which the coher- 
ence relationships are included yet. Obviously, both solutions are not acceptable, 
when NeMo+ is used as a solver in Sketcher programs. It is more preferable that 
the solver make itself the decision what relationships are necessary to be taken 
into consideration for solving the given problem. In order to do that, a special- 
ized library was implemented in the NeMo+ environment, which can be consid- 
ered as a NeMo+ geometric modeler. In our view, the NeMo+ geometric mod- 
eler is an ’’intelligent” instance solver, which is able to solve well-constrained, 
under-constrained, and over-constrained (but consistent) problems. Using the 
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partial constraint satisfaction tecniques it also can solve the over-constrained 
(and inconsistent) geometric problems. The NeMo+ geometric modeler was im- 
plemented by E.V. Roukoleev. The partial constraint satisfaction algorithms 
were implemented by D.M. Ushakov. 

The geometric modeler allows NeMo+ to compute the model, which contains 
only the elementary geometric objects (points, lines, angles, . . . ) and constraints 
(perpendicularity, parallelism, distance, ...). Using this information and the 
intermediary results, obtained during the constraint propagation, the modeler 
generates new constraints on parameters of the model. The modeler uses three 
methods for changing the model: unification, decomposition, and synthesis. 

Unification. The basic geometric objects like points, lines and planes are 
considered for this method, and for each of them the concept of ’’index” with 
the following properties is determined (for objects of the same type): 

1. Index(a)=Index(6)<=>a=6<=>Distance(a,&)=0; where Index: G^Z. 

2. If X = U(ai, 02 , . . . ,aiv), V = F( 6 i,& 2 , • ■ • ,&at), and 

Index F{Index{ai ) , . . . , Index(aN)) = IndexF{Index{bi ), . . . , Index{bN)), 

then X == y, where Index f :ZxZx...xZ^Z. Thus, if in the model there 
are constraints of equivalence or of equality to zero of distances, the unification 
of the appropriate objects is done. And if the arguments of functions are unified, 
their results are unified too. 

Decomposition. Usually the complex relations are expressed through the 
more simple ones. During the interpretation of the complex relation the modeler 
try to determine if some of its more simple components exist in the model or 
not. If a more simple relation exists, then the modeler doesn’t create a new 
component and uses the existing one. 

Synthesis. When we have a lot of constraints linked to the same object, 
sometimes it is possible to create for this object a stronger relation. For example. 

On (Point A , LineAB) &0n (PointB , LineAB) ->LineAB=0n (PointA , PointB) ; 

In the case of three distances AB, BC and AC, this technique allows the 
modeler to find out the contradictions before setting up the coordinate values: 

AB + BC >= AC] 

AB + AC >= BC] 

AC + BC >= AB] 

Using this technique it is possible to solve not only the common geometric 
problems but also the optimization ones, containing engineering constraints. For 
example, one can find such a configuration of a complex sketch than the sum 
of areas (engineering constraints) of some closed contours consists exactly N 
percents of the area of the whole sketch. 

The first step of validation of the modeler has been achieved with success for 
a set of examples in 2D-geometry. 
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3 Constraint Solver in Conceptual and Assembly Design 

A CAD/CAM products mostly consist of a number of parts (which are made 
of features) that are connected to each other. The ideal product modeling sys- 
tem should therefore be able to support the modeling of all parts and their 
connections. Assembly constraints provides information on which component is 
connected to which other component in what way (face-contact), thus represent- 
ing a model of an assembly. A CAD/CAM system must maintain the consistency 
of the designed product. 

The design of a product can be thought of as a top-down (Conceptual Design) 
and/or bottom-up (Assembly Design) processes. Both of them can be considered 
as a sequence of phases, each of which adds information to the product model. 

In the early phases of conceptual design, in which all global product require- 
ments are gathered into the model, the designer does not yet want to think about 
all kinds of details that are not directly related to these requirements. In these 
phases, the designer only wants to specify those parts and constraints that are 
needed to satisfy the global requirements. 

An assembly is a collection of parts, assembly features (coordinate systems, 
datum entities) other assemblies, and assembly properties. In the assembly the 
designer takes the ready-to-use parts and connects them by constraints according 
to the product requirements. If changes occur in one component the constraints 
can take care of the propagation of these constraints. This propagation can be 
authomatically done by solvers like NeMo+. Moreover, in the case when there 
exists libraries, catalogues of standard elements (parts, products), NeMo+ can 
be used for the intelligent search of such elements. The NeMo+ object-oriented 
language allows the designer to specify the query in high-level terms of the given 
data domain. It is possible to associate to the query more sofisticated require- 
ments such as systems of equations, inequalities, rules (conditions), diagrammes, 
indicate the possible alternatives, etc. The end-user query is associated to the 
NeMo+ model, elaborated and implemented by an expert. The solver, as we have 
mentioned before, returns the subdefinite result (the set of possible solutions) 
and one exact solution. 

For example, a fragment of an expert model, which provides the choice of a 
bearing type from the given catalog, looks as follows: 

B: Bearing; 

B.PO == B.Fr + (0.5 *B.Fa); B.L10=(B.C / B.P)~B.p; 

if B.Types2 == 2 then 
B.d == [ 3.0, 160.0 ] ; 

B.D == [ 10.0, 240.0 ] ; 

if ((311 <== B.Num)/\(B.Num <== 486)) // Kind of joints 

then ((-30 <== B.T)/\(B.T <== 110)); // Limits of temperature 

end; 

if (((B.T»20) /\ (B.T«120) /\ (B.nu»5.01) /\ (B.nu«400)) 

\/((B.T»20) /\ (B.T«120) /\ (B.nul»5.0) /\ (B .nul«400) ) ) 
then DIAGRAMME2 ( B.nu, B.T, B.nul ); 
end; 
end; 
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It should be noted once more that the values of parameters in all assembly 
or conceptual design components can be subdefinite. They become more and 
more exactly in the design process, when new components and new constraints 
arise in the product. This is the main difference between the proposed approach 
and the well-known existing industrial CAD/CAM systems, which assume that 
components are completely specified before assembly modelling is performed. 



4 Constraint Solver in Knowledge Component 

The use of the Knowledge component in a CAD system gives to the designer the 
following possibilities: 

— Create and manage rules and knowledge bases; 

— Check rules and knowledge base compliancy after design; 

— Invoke knowledge base advisor during design. 

The NeMo+ environment can be used in the Knowledge component as a ba- 
sic solver, which provides the rules checking, tables computation, optimization, 
constraint satisfaction, and solving a complex system of equations, inequalities, 
including real numbers, integers, strings, booleans, sets, and user-defined types. 

Currently NeMo+ is incorporated in the Knowledge component of a 
CAD/CAM system, where it represents a very clear concept for the user: a 
set of equations and inequalities. Such a set is defined in terms of mathematical 
equalities and inequalities and can include arithmetic, trigonometric and other 
standard mathematical functions. The user can arbitrary divide the parameters 
included in the set of equations (e.g. cost, material, distance, angle, area, volume, 
etc.) into two groups: inputs and outputs. Values of the input parameters are 
taken from the product, the output ones should be calculated by the solver. So, 
the interactive changing of input values enforces outputs to be recalculated by 
NeMo+. This behavior allows the user to optimize any parameter under design 
by easy switch between inputs and outputs. The implementation of the set of 
equations has been done by D.M. Ushakov. 



5 Constraint Solver in Mannfacturing &; Data 
Management 

Increasingly, CAD/CAM research is concerned with developing an integrated 
approach, incorporating the activities of design, manufacturing, process man- 
agement and maintenance. 

An advanced CAD/CAM system will have the following capabilities: 

1) Integrate design-to-order and scheduling so as to calculate delivery dates. 

2) Allocate resources and schedule the work of different teams, throughout 
the product life cycle, from design, through production and to disposal. 

Obviously, the advantages of NeMo+ for solving a calendar planning and 
job-shop scheduling problem is the possibility to deal with intervals of begin- 
ning, ending, and duration of jobs [13]. In order to solve more efficiently time 
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scheduling problems, a specialized library of NeMo+, a JobShopScheduler, was 
implemented. 

JobShopScheduler is a solver for use by applications with a need for solv- 
ing job-shop scheduling problems such as well-known bridge building planning 
problem. This solver deals with jobs (that may, in turn, consist of smaller sub- 
jobs), which need to be scheduled according to constraints that link those jobs 
together. The constraints may concern jobs’ precedence, their possibilities to 
perform at a given time, simultaneously with another jobs etc. The important 
feature of the solver is the presence of the notions of a resource, resource pool, 
and resource allocation. This allows us to state and solve complex optimization 
problems where jobs’ processing requires certain resources and resources have 
limited capacity. 

One of the possibilities of the problem specification as PERT chart is shown 
in Fig. 2. 
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Fig. 2. Specification of a job-shop scheduling problem 



JobShopScheduler is implemented as a C-| — h library which includes a set of 
basic constraint types derived from NeMo+ ones, and also high-level constraints 
expressing most often used relationships between jobs and resources. This library 
has been implemented by V. S. Markin. 
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6 Conclusion 

In the paper, we proposed the way to use constraint programming solvers in 
different components of a CAD system. In order to allow end-users to make 
a maximum profit, it is necessary that features support approximately known 
values of designed entities, and these values should be persistent in the model. 
The NeMo+ constraint programming environment (or the solver with the same 
capabilities) is proposed to be used. 

NeMo+ is implemented in C-|— I- under Windows and UNIX platforms. There 
are no restrictions on the kind of constraints it can solve. One can build NeMo+ 
specialized solvers in order to make it more efficient. 

The applicability of this approach was proven by prototyping the geomet- 
ric, and JobShopScheduler solvers in a CAD/CAM programming development 
environment, and by an integration of the NeMo+ solver in the Knowledge com- 
ponent of the CAD/CAM system. 

The forthcoming work will include the extention of NeMo+ possibilities to 
process not only the functions implemented in its libraries, but also the external 
functions. Another interesting topic for NeMo+ is the distributed and collabora- 
tive design. We hope, that in the future, NeMo+ (or a NeMo+-like sover) will be 
integrated in the kernel of a CAD / CAM system for providing a general-purpose 
solution for the update engine of a CAD / CAM system. 
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Abstract. We propose a language composed of basic graphical compo- 
nents. By assembling these components as in a Lego game, solver co- 
operations can be visualized. The advantage is to represent by simple 
figures complex cooperations that usually requires tedious descriptions. 
We illustrate our language by implementing some well-known coopera- 
tive solvers. 



1 Introduction 

Solver cooperation [S] is now well-known as a concept for improving efficiency 
and performance of constraint solvers. Generic solvers are generally far too in- 
efficient for solving numerous real-life problems. However, a large part of these 
problems can often be handled by “incomplete” but specific and efficient solvers; 
furthermore, a solver can pre-process constraints in order to ease and speed-up 
a second solver. 

The most usual type of cooperations (that we call ad-hoc cooperations) are 
based on one cooperation concept {e.g., sequential solving process such as in 
CoSAc [H] or in the system of Beringer and Debacker jl], or concurrent commu- 
nication such as in the system of Marti-Rueher CD) and one solving strategy: 
the solvers are known, and the rooting of constraints through the solvers is 
fixed a priori. Examples of such cooperations are innn]. Implementing ad- 
hoc cooperations is a tedious task that involves several different problems, such 
as implementing communication between solvers, fixing interoperability prob- 
lems, filtering constraints, synchronizing solving processes, and in the worst case 
re-implementing solvers from scratch. 

On the one hand, cooperation languages [12ll7l8fT| recently emerged as a new 
concept for designing and automatically implementing (such as in jl2] l solver 
cooperations as expressions of a calculus-like language. However, cooperation 
expressions quickly become difficult to read. Moreover, interactions and commu- 
nications between solvers are not explicit, but are hidden in the definitions of 
the primitives for building expressions. 

On the other hand, the concept of coordinating a number of activities, run- 
ning concurrently in a parallel and distributed fashion, has recently received 
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wide attention {e.g., see |T6]). Visual interfaces to such languages already exist, 
such as the Visifold interface j5] for the control-driven coordination language 

Manifold [T]. 

Some works have already been conducted to relate cooperation and coordi- 
nation m, and to use coordination facilities for solver cooperation |2] . However, 
to our knowledge, visual interfaces (similar to visual interfaces of coodination 
languages) have not been integrated in solver cooperation languages. 

In this paper, we propose a language for graphically designing solver coop- 
erations. This language is composed of some few basic components from which 
more complex bricks and solver cooperations are built such as in a Lego game. 
Usual patterns of cooperation (such as sequential, concurrent, and parallel solv- 
ing processes), and standard control on constraint routing (such as conditional, 
fixed-point, selections) can easily be designed linking solver, control, filter, and 
selection agents with channels of communication. Complex cooperations are then 
built connecting these patterns of constraint processing. This language aims at 
representing graphically in a unified and simple way solver cooperations. The 
growing capacity of this language is tremendous: first, patterns of cooperations 
can become new bricks of the language, and second, new basic components can 
easily be integrated. Moreover, adding a new component correspond to imple- 
menting a new module that does not interfere but interact with previous pieces 
of code. 

We illustrate the practicality of our language by “simply” visualizing some 
ad-hoc cooperations (such as the ones of | 4l3p that normally require long de- 
scriptions. 

The outline of this paper is the following: definitions for constraints, solvers 
and filters are presented in Section |2] Basic graphical components are described 
in Section [3] in terms of communicating agents. Using these components, some 
standard patterns of cooperation are designed in Section |4l before visualizing 
some well-known ad-hoc cooperations in Section]^ We finally conclude in Sec- 
tion!^ 

2 Framework 

Let 2? be a set called the universe, T a set of function symbols, TL a set of relation 
symbols, V = (V, T, TZ) a structure, and X = {xi, ... , x„} a set of variables. A 
constraint language £ is a non-empty set of first order (S,X)- formulae. Given 
a constraint c on variables xi, . . . ,x„, let pc denote the underlying relation on 
2?". The relation associated to the constraint c on Xj^, ... ,Xi, is extended to 
the set P+ = {(xi, . . . ,x„) G 2?" | {vi ^^ ... ,Xi,) G pc}- A constraint store C is 
given as a set {ci, . . . , Cm} of constraints from C interpreted as the conjunction 
Cl A ■ ■ ■ A Cm- The solutions of C (denoted by Sol{C)) are defined as: 

m 

Sol{C) = f| 

2=1 
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£5 represents the set of stores built upon the constraint language £. We can 
now define the notion of solver in our scheme. 

Definition 1 (Solver). Consider a constraint language C. Then, a solver S 
on C is a computable function S : Cs — > £5- 
A solver is said: 

correct: ifWC G Cs, Sol{S{C)) C Sol{C) 

complete: if'iC G Cg, Sol\c) C Sol{S{C)) 

With respect to Definition [H Grobner basis computation, Simplex, Gaussian 
elimination, factorization of polynomials, trigonometric transformations are sol- 
vers. No property is required a priori for solvers. However, some properties of 
solver cooperations are induced from solver properties (see e.g., dispatcher in 
Section |4) . 

Definition 2 (Cooperation). Consider k solvers Si,... ,Sk respectively on 
Cl,... ,£fe, and a constraint language C. We say that solvers Si,... ,Sk on 
Cl, ... , £fc can cooperate on C if: 

Vf G [l,fc], Ci C £. 

Stores from Ci are called admissible constraints of St on C. 

The role of filters is very important for cooperations on a language £. They 
select parts of constraints stores, i.e., subsets of stores in order to: 

1. select constraint stores a solver S' on £' C £ can actually handle, i.e., the 
admissible constraints of S on £, 

2. and, treat efficiently subsets of stores by specific solvers. 

Definition 3 (Filter). Consider a constraint language C. A filter on C is a 
computable function ip : C$ — > Cg such that: 

VC G Cg, if{C) C C 

Usual filters are :^eq_poiy to filter polynomial equations, t/Jun to filter linear con- 
straints, etc. 

Property 1. A filter is a complete and non correct solver. 

Filters can be combined using intersection, union, and complementary oper- 
ators to compose more complex filters. The results are the expected standard set 
operators on stores of constraints. Gonsider two filters <pi and p 2 on £. Then, 
for all C G Cg, we have: 

{pi U P2){.C) = pi{C) U P2{C) 

{pi n P2){C) = pi{C) n ip2{C) 

p{C) = C\p{C) 

The reader can refer to j7] for more complex examples and a more complete 
presentation of filters. 
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3 Basic Graphical Components 

We design a set of graphical — basic — components that can be combined to 
implement solver cooperations. The underlying model is based on agents — 
solvers, filters, selectors, etc. — acting on constraints. An agent receives data on 
input ports, transforms them, and puts the resulting data on output ports. Ports 
of agents are connected by channels, where a channel transfers a constraint store 
from an output port of an agent to an input of another agent. 

The basic graphical components are presented in Figure [T] Their precise 
meanings will be explained in the following. 




Fig. 1. Basic graphical components 



3.1 Communication 

Communications of constraint stores are modeled by ports — holes on agents — 
and channels — linkers of ports. A port either models an input of an agent, or 
an output. A channel implements a one-to-one (from an output port to an input 
port) communication of constraint stores. 

In the following, we propose agents achieving solver computations, and fil- 
tering, controlling, and redirecting communications. 

3.2 Solving Agents 

Solving agents (Primitive solue in Figure [T|) capture the computational part of 
cooperations. In fact, most of existing systems integrate a restricted set of al- 
gorithms (such as Grobner bases [B], consistency techniques m, interval meth- 
ods etc.) that are seen as black-box solvers. Consider a solver S. Then, from 
an input constraint store C (available on the input port), if C belongs to the 
constraint language of S, then S is applied on C {S{C) = C), and the new store 
C is delivered on the output port; otherwise, S is not applied, and C = C\ 
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when C on input 

if C in Icinguage of S 

then put S{C) on output 
else put C on output 



3.3 Transformer Agents 

Transformer agents are essentially solvers processing constraints by means of set 
operations: restriction, union, conjunction, etc. We briefly discuss four kinds of 
useful operations. 

Filter. A filter agent (Primitive filter in Figured) applies a Alter Lp (see SectionE) 
on C to extract a subset of the constraints verifying some property, i.e., C = 
(f{C) such that C C C: 

when C on input , put (p{C) on output 

A Alter is generally used to preprocess a constraint store before applying a spe- 
cific solver. 

Clone. Cloning (Primitive clone in Figure [T| a constraint store C consists in 
duplicating C on every output ports. 

when C on input , put C on output 1 auid put C on output 2 

Note that the combination of several cloning agents increases the number of 
clones: n—1 combined cloning agents lead to n clones. Cloning agents are useful 
for realizing different usual tasks of cooperation, such as modeling concurrent 
algorithms, and processing of sub-stores. 

Clue. Cluing (Primitive glue in Figure [T| constraint stores C and C means 
generating their union C" = CcC . This operation is performed when all input 
stores are available on input ports. 

when C on input 1 , and C' on input 2 , put C C C' on output 

Typically, it gathers together results generated by cooperative solvers acting on 
the same constraint store (competitive concurrent solvers), or acting on disjoint 
sub-stores (cooperative concurrent solvers). 

Select. The selection (Primitive select in Figured) of two input constraint stores 
C and C' transfers just one of them to the output port. We have either C” = C 
or C" = C: 



when C on input 1 and C' on input 2 , put C or C' on output 
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3.4 Control Agents 

A control agent manages the rooting of constraint stores during the solving 
process. We identify agents modeling switches and fixed-point computations. 

Switch. A switch (Primitive switch in Figure [I]) is based on a P function from 
stores to Booleans: P checks whether input constraint stores verify a given prop- 
erty or not. Consider a P function and an input store C: if P{C) is true, then 
C is transferred to the output port t, otherwise to the output port /: 

when C on input , 
if P{C) 

then put C on t 
else put C on f 

Switches represents conditional of m-- they are very important to dynamically 
control solver cooperations. 

Close. A more complex kind of switch (Primitive close in Figure H]) is devoted 
to fixed-point computations. It is based on the detection of equivalent consecu- 
tive input constraint stores. For this purpose, such an agent has a memory — a 
constraint can be stored between consecutive applications — , two input ports i 
(input) and r (re-enter), and two output ports / (follow) and fp (fixed-point). 
The computation processes are as follows: 

— Initially, the memory is empty. The first time a constraint store C is received 
on i (input port), it is stored in the memory, and also put on port / (follow 
port). 

— Then, when a constraint store C' arrives on r (re-enter port), it is compared 
with the memory. If they are equivalent, C is put on port fp (fixed-point 
port) and the memory is cleared and reset for next use — the fixed-point is 
just detected. 

— If they are different, C is put on port / (follow port) and the memory is 
updated with C . 

The close agent can be described as follows: 

when C on i, put C on f aind M = C 
when C on r, 

±f C = M 

then put C on fp 

else put C on f and M = C 



4 Standard Patterns of Cooperation 

We now describe two patterns involved in numerous cooperations. 
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Fig. 2. Solver protection 



Solver protection. When using a solver protection (Figure[2| solvers process only 
subsets of the constraint store (i.e., their admissible constraints, constraints they 
can effectively handle), while the rest of the input store is preserved, and used 
to create the new constraint store. More precisely, the input store is first cloned. 
Then, 

— on one branch, the store is filtered by ip to extract from a constraint store 
C the admissible constraints of S. S is then applied on the resulting store; 

— on the other branch, the filter ip (i.e., the complementary of p) filters C \ 
p(C). 

The output of S, and the non-admissible constraints of S are then glued together: 
the final output of the protection is: {C \ p{C)) U S{p{C)). 

Property 2. Consider a solver S, and p to filter its admissible constraints. If S 
is complete, then the protection of S is also complete. 




Fig. 3. Dispatcher of a store to solvers 



Dispatcher. A dispatcher (Figure [3) distributes constraint store to n solvers 
(each of them being associated with a specific filter) using n — 1 cloning agents. 
Note that it can also be combined with a solver protection to preserve the whole 
of the input store. 
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5 Modeling Existing Systems 

We design three existing cooperative solvers to illustrate the feasibility of our 
approach. 




input output 



Fig. 4. Cooperation Simplex-interval solver on linear constraints 



Cooperation for linear constraints. The system of Beringer and Debacker jl] is 
devoted to linear constraints: domains of variables are reduced with an interval 
solver while a Simplex-like solver tries to detect inconsistency of stores and to 
fix variables. As soon as new information is deduced by one of the solvers, it is 
communicated to the other one. The process terminates when a fixed-point is 
reached, i.e., none of the solver is able to deduce new facts anymore. This coop- 
eration is visualized in Figure [4l The solvers are applied in sequence, each one 
processing the whole constraint store. The detection of a fixed-point is realized 
by a closure agent. 



Groebner basis on a partition 




Fig. 5. Cooperation Grobner basis-interval solver on arbitrary constraints 



Grobner basis computation and interval solver. The cooperation of Grobner 
basis computation used as a preprocessing for an interval solver is visualized 
in Figure O The input constraint store is filtered in order to extract the set of 
polynomial equations. A set of Grobner bases is then computed for a partition 
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of the set of polynomial equations (construction cloning- filter-solver) . The input 
of the interval solver is the union of the computed Grobner bases and the input 
constraints that are not polynomial equations. 



Interval 




Fig. 6. Cooperation Grobner basis-Simplex-interval solver 



Grohner basis computation, Simplex, and interval solver. Figure [^illustrates the 
following cooperation: a Grobner basis is generated for polynomial equations, 
and they are combined with the other input constraints. Then, a fixed-point of 
the Simplex and an interval solver applied in sequence is computed. A filter of 
linear constraints is necessary in front of the Simplex, while the interval solver 
handles all constraints (linear and nonlinear constraints are combined after the 
application of Simplex) . 



6 Conclusion 

In this paper, we have proposed a language for visualizing solver cooperations in 
a unified and graphical manner. This language is composed of basic components 
that are then linked together by channels in order to graphically represent solver 
cooperations. Gomplex cooperations that usually require long explanations are 
described by a simple figure in our language. The growing capacity of the lan- 
guage are tremendous since integrating a new basic component corresponds to 
adding a module in a component based-framework and does not provoke any 
side-effect. 

We are confident in the practical realization of our language to automatically 
implement solver cooperations from their graphical descriptions: cooperation 
features are similar to primitives of BALI (which has already been implemented), 
and more complex visual interface (such as j^) have already been realized for 
complete coordination languages (such as Manifold |T] which requires several 
complex communication and interaction features). 
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In the future, we plan to extend our language by introducing several types 
of communication in order: 

1. to enable solvers waiting for complementary constraints, 

2. and, to manage disjunctions of constraints {e.g., several possible solutions) 
as different constraint stores requiring different solving processes. 
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Abstract. Partial multi-valued functions represent semantics of non- 
deterministic programs. The notion of naturally computable partial 
multi-valued function is introduced and algebraic representations of com- 
plete classes of naturally computable functions over various data struc- 
tures are constructed. 



1 Introduction 

The title of this paper is a clear reminiscence of A.P. Ershov’s articles “Abstract 
computability on algebraic structures” [Ij and “Computability in various do- 
mains and bases” [2]. This tight connection of titles is not accidental and has 
a long history. The story goes back into 1984 when the author being on a sab- 
batical leave from the Kiev State University spent half a year in Novosibirsk at 
the A.P. Ershov’s department of the Computer Center of the Siberian Branch of 
the Soviet Academy of Sciences. During his stay in Novosibirsk the author had 
the possibility to study the intentions of Ershov’s works on computability, was 
fascinated by his ideas and tried to follow them in his own investigations. The 
author is grateful to A.P. Ershov for support in his work on the topic. 

The main objective of Ershov’s works on computability was the necessity to 
develop for computer sciences their own fundamental conceptions of the com- 
putability theory [T]. Such a theory must define computability for various subject 
domains and different systems of basic operations; clearly distinguish combi- 
natorial and “executable” aspects of computability; be independent of specific 
program syntax and mechanisms of program evaluation 

The author’s research on computability are based on the following ideas of 
A. P. Ershov: 

- the notion of abstract computability must be oriented on abstract models 
of programs, 

- abstract computability has a relative character, 

- the notion of determinanlQ can be used for the definition of function com- 
putability. 

^ A.P. Ershov understood determinants as sets of special terms constructed over given 
algebraic system 

D. Bj0rner, M. Broy, and A. Zamulin (Eds.): PSI 2001, LNCS 2244, pp. 468- 14811 2001. 

(c) Springer-Verlag Berlin Heidelberg 2001 
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To realise these ideas we 

- construct abstract but powerful models of programs, 

- define exact definitions of computability, which satisfy the described re- 
quirements, 

- study the properties of introduced notions of computability. 

Such definitions were first developed for the compositional model of programs 
| |3I4| . The notions of natural and determinant computability were introduced 
and the complete classes of functions and compositions over different classes of 
named data were described. In this paper we extend this approach to new more 
general classes of program models, based on composition nominative principles 
1^. The main extensions concern computability over nominative data for non- 
deterministic programs. 

The paper is structured in the following way: 

- first, we define composition nominative systems, which can be considered 
as abstract powerful program models, 

- then, we discuss questions of computability in programming languages 
and define the notion of natural computability of partial multi-valued functions, 
which represent semantics of non-deterministic programs, 

- at last, complete classes of computable partial multi-valued functions over 
different specializations of nominative data structures are described. 



2 Composition Nominative Approach to Program 
Definition 

The main goal of the approach is to construct a clear hierarchy of adequate 
program models of various levels of abstraction and generality. Dialectical logic 
developed by G.W.F. Hegel and his followers is used as a gnoseological (episte- 
mological) foundation of this approach. 

The approach is based on the following principles, which specify the main 
program notions. 

Development principle (rising from abstract to concrete): the no- 
tion of program should be introduced as a process of its development, which 
starts from abstract understanding capturing essential program properties and 
proceeds to more and more concrete considerations thus gradually revealing the 
notion of program in its richness. 

Applicativity (functionality) principle: at the highest abstraction level 
programs can be considered as functions which being applied to input data can 
produce output data. 

Function nominativity principle: programs can be presented as names 
denoting functions which being applied to input data can produce output data. 

Compositionality principle (V. Red’ko [6j): programs can be considered 
as functions which map input data into output data, and which are constructed 
from simpler programs (functions) with the help of special operations, called 
compositions. 
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Descriptivity principle: programs can be considered as descriptions (com- 
plex names) which denote functions constructed from simpler functions with the 
help of compositions. 

These principles introduce five notions: data, function, function name, com- 
position and description, which form the pentad of main program notions. For- 
malizations of such notions are usually based on the notion of set, thus giving 
set-theoretic formalizations of programs. Still, there are proposals to use instead 
the notion of function |Z]. Here we will follow this way considering a function- 
theoretic approach. 

Principle of function-theoretic formalization: program notions are for- 
malized on a base of a function-theoretic approach. 

Please note that we do not reduce the notion of set to the notion of function. 
But we do not either adopt the traditional reduction of the notion of function 
to the notion of set. Thus, we treat the both notions as mutually dependent on 
each other. 

Taking into account the development principle we come to the conclusion that 
we need a special theory which permits to study functions on various abstraction 
levels. We propose to call such a theory as DEFT Theory (DEveloping FuncTion 
Theory). Abstract computability, presented in this paper, may be regarded as 
an integral part of this theory. 

Functions, which maps elements of A into i?, are considered in the most gen- 
eral way as partial multi-valued functions. In this case functions are not uniquely 
represented by their graphs, therefore we will additionally take into considera- 
tion the sets of elements on which functions can be undefined (undefinedeness 
sets). For example, function / = [1 >->• 1, 1 >->• 2, 1 >->•, 2 >->•, 3 >->■ 1] has a binary 
relation {(1,1), (1,2), (3, 1)} as its graph and a set {1,2} as its undefinedeness 
set. We will use the following notations for the classes of functions: 

- D ^ D - partial multi-valued functions, 

- D ^ D - partial single- valued functions, 

- D \ D - total single- valued functions. 

Program models on high abstraction levels can be presented as composition 
nominative systems [^. Such a system may be considered as a triple of the 
following simpler systems: composition, nominative, and denotational systems. 
Composition system defines semantic aspects of programs, nominative system 
defines program descriptions (syntactic aspects), and denotational system spec- 
ifies meanings of descriptions. Here we will consider only composition systems 
which are triples of the form < D,F,C >, where D is a set of data, on which 
programs are defined, F C (D ^ D) is a class of partial multi-valued func- 
tions, representing program semantics, and C is a class of compositions over F, 
representing program construction means. 

These definitions are specialised for more concrete levels. We can distinguish 
three main levels: abstract. Boolean, and nominative levels [^. The last level 
is the most interesting level for programming. On this level program data are 
considered as nominative data, which are constructed hierarchically with the 
help of naming relations. 
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For given sets of names V and basic elements W the class of nominative data 
ND(y, W) can be presented by induction or by the following recursive definition: 



Main unary operations over nominative data with the name u as a parameter 
are the following. 

— Naming operation =>u. Being applied to some data d it yields the nominative 
data having the only component with the name v and the value d. 

— Partial multi-valued denaming operation u=>. Being applied to some nomi- 
native data d it yields one (arbitrary chosen) value of the name v, if at least 
one component with the name v is in d. 

— Deleting operation \v. Being applied to some nominative data d it deletes 
one (arbitrary chosen) component with the name v, if such a component is 
in d. 

— Checking operation u!. Being applied to some data d it yields the empty 
nominative data 0, if v has at least one value in d, and d, if v has no value 
in d. 

Main binary operations over nominative data are the following. 

— Override operation [Sj f. Being applied to nominative data d and d' it yields 
a new nominative data, which has as its components all components of d' 
and those components of d, the names of which do not occur in d' . 

— Union operation U combines two nominative data yielding a new data, which 
has all components of the arguments. 

— Subtraction operation \ deletes from the first nominative data those compo- 
nents, which belong to the second nominative data. 

We also use non-deterministic choice operation, which on d yields d or 0. 
Functions of the set F = ND(V, W) ^ ND(V, W) are called nominative 
functions. The main compositions defined over F are binary compositions, de- 
scribed by the following formulas, where f,gGF,d£ ND{V,W). 

— Multiplication (functional composition) : {f o g){d) = g{f{d)). 

Note that / is applied first and g second. 

— Iteration. This composition is similar to the operation while-do and can 
be easily defined inductive, but for simplicity we present here its recursive 
definition: 



ND{V, IF) = VF U (U 4 ND{V, IF)). 




Here 0 is the empty nominative data. 
Overriding: {fVg){d) = f{d) f g{d). 
Summation: (/ U g){d) = f{d) U g{d). 
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In all cases, when certain application of a function to some data in the right- 
hand side of a formula is not defined, then the result of the left-hand side of the 
formula is also undefined. 

Concretizations of nominative data can represent various data structures, 
such as records, arrays, sets, tables, etc. m- For example, a set {si, S 2 , ..., Sn} 
can be presented as a nominative data [1 i— >■ si, 1 i— >■ S 2 , 1 i— t s„], where 1 is 

treated as a standard name. Thus, we can formulate the following principle. 

Data nominativity principle: program data structures can be presented 
as concretizations of nominative data. 

Having defined composition nominative systems as powerful program models 
(models of programming languages), we can now specify special computability 
for such models. 

3 Computability in Programming Languages 

Conventional programming languages are usually called universal languages. It 
means that their programs define computable functions, and vice versa, any 
computable function may be represented by a certain program, written in such 
a language. But more thorough investigation reveals a number of difficulties, 
which are concerned with our understanding of computability in programming 
languages. Usually computability is understood as computability of n-ary func- 
tions defined on integers or strings. Such computability may be called Turing 
computability. But programming languages also work with other data struc- 
tures and it turns out that for these structures programming languages, which 
are considered as universal, may not be universal. That is: their programs cannot 
represent all computable functions definable on these structures [^. 

To study this problem we need its exact formulation. It seems natural to 
start with the set D of all data definable in a language and then consider this 
language as universal (or computationally complete), if its programs represent 
the class of all computable functions from D to D. Under this formulation it 
is well known that Pascal, for example, is not complete, because it is forbidden 
to use dynamic arrays and consequently it is impossible to write a program 
(procedure) for multiplication of matrixes with changing dimensions. 

Typing is not the only reason of computational incompleteness. For conven- 
tional programming languages a more important reason is absence of facilities for 
dynamic construction and analysis of data structures. For example, conventional 
languages usually do not have facilities to check whether a variable has a value or 
not. Some languages, say, Ada, to cope with such difficulties use a mechanism of 
exceptions, like NO_VALUETlRROR, INDEXJERROR, RANGEJERROR, etc. 
However, not much attention is paid to completeness problems in programming 
languages. Similar situation arises in database query languages, when many of 
them are computationally incomplete. The requirement of computational com- 
pleteness was even declared in “The object-oriented database manifesto” [0]. 

So, the computational completeness of programming languages is not a trivial 
problem and calls for specific further investigations. 
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The completeness problem is not the only aim of our investigation. Now it 
is a common opinion that programs should be developed successively from ab- 
stract specifications via more concrete representations up to detailed implemen- 
tations in chosen programming languages. And it is very important to connect 
completeness and computability problems with stages of program development. 
We intend to introduce such unified notions of computability and completeness 
that can be applied to every stage of program development and can be easily 
transformed when moving from stage to stage of development. Such a kind of 
computability should be applicable to data structures of different abstraction 
levels and is called abstract computability |Tj. In fact, such computability is a 
relative computability - relative to data structures and operations over them. 

Another facet of the problem is formulation of simple and clear descriptions of 
complete classes of computable functions on each level of abstraction. We shall 
construct algebraic representations of such classes. It means, that a complete 
class will be described as the closure of some basic functions under a certain 
(and very simple) class of compositions (operators over functions). 

Many results are currently available in this area. We only mention 
11 ,‘ 111411, ^11 b] . However, despite the richness of the available results, the attempt 
to apply them to our problems runs into various difficulties. 

The point is that many approaches postulate certain requirements which, 
first, are far from obvious and themselves require substantiation, e.g., the ex- 
istence of a universal computable function, as assumed by Strong, Freedman, 
Moschovakis, and second, are often inapplicable to specific data structures, e.g., 
the requirement of data enumerability of Mal’tsev’s enumeration approach, or 
the requirement of Goedelisation of Wagner’s approach (see refs, in 0). Recall 
that we are concerned with computability defined in terms of data structures of 
programming languages. We will therefore try to motivate the proposed formal- 
ization of computability by using weaker postulates, from which other postulates 
may be obtained as corollaries (as suggested by Gandy [TO] and Scott my In 
other words, we will attempt to identify the key ideas of abstract computability, 
which can be combined to obtain concrete results. 

We will study computational completeness of the classes of functions over 
nominative data. The difficulty of the problem lies in the fact that the notion 
“computability over complex data structures” by itself must first be defined and 
then, only on this basis, complete classes of functions can be described. 

Here we restrict our consideration only by computability over finite data 
structures, which is called natural computability. 

4 Natural Computability of Partial Multi-valued 
Functions 

In order to formalise computability of functions over finite data structures, we 
first need to define such data. This is a difficult question, and we will accordingly 
adopt the following strategy: we will first define a special form of finite data 
structure and subsequently reduce data of other forms to this special form. 
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Our intuitive notion of a finite data structure is the following: any such datum 
d consists of several basic (atomic) components 5i, ...,6m, organised (connected) 
in a certain way. If there are enumerably many different forms of organisation for 
finite data structure, each of these data can be represented in the (possibly non- 
unique) form {k, < bi, ..., 6m >), where k is the datum code and the sequence 
< 6i,...,6m > is the datum base. Data of this form are called natural data 
|3|. More precisely, if B is any set and Nat is the set of natural numbers, then 
the set of natural data over B is the set Nat{B) = Nat x B*. 

A set D is called a set of finite data strncture (over B with respect to nat), 
if a set B and a total multi-valued injectiv^l mapping nat : D ^ Nat{B) are 
given. This mapping nat is called the naturalization mapping, and the partial 
single-valued inverse mapping nat~^ : Nat{B) D, denoted by denat, is called 
the denaturalization mapping. 

Very often the denaturalization mapping is called the abstraction mapping. 
We prefer to start with naturalization mapping as primary, because our defini- 
tions are developed in the direction from abstract levels to concrete ones. 

The introduction of natural data and naturalization mappings enables us 
to reduce computability over D to special computability over Nat{B), which 
is called code computability. To define this type of computability we should 
recall that in natural data the code collects all known information about datum 
components. Thus, code computability should be independent of any specific 
processing tools of the elements of the set B and can use only those tools which 
are independent of B and are explicitly exposed in natural data. The only explicit 
information in natural data is the datum code and the length of the datum 
base. Therefore in code computability the datum code plays a major role, while 
the elements of the datum base are “extras” that virtually do not affect the 
computations. The elements of a datum base may be only used to form the base 
of the resulting datum. To describe the code of the resulting datum and the 
order in which elements of the initial base are put into the base of the resulting 
datum, a special function of type Nat^ ^ Nat x Nat* should be used. Such 
functions are called index computable functions. These considerations lead to 
the following definition. 

A function g : Nat{B) ^ Nat{B) is called code computable, 
if there exists an index computable multi-valued function h : Nat^ ^ 
Nat X Nat* such that for any k^m £ Nat, 6i,...,6m G B, m > 
0 g(fc, < 6i, ...,6m >) = (fc', < 6q, ...,6i, >), if and only if h{k,m) = 
(fc',< ii, ..., ii >), 1 < < TO, ..., 1 < < TO. If at least one of the indexes ii, ..., q 

lies outside the interval [1, to], or h{k,m) is undefined, then g{k, < 6i, >) 

is also undefined. 

In other words, in order to compute g on (fc, < 6i,...,6m >), we have to 
compute h on (k,m), generate a certain value (fc',< >), and then try 



^ A multi-valued function is injective, if it yields different values on different argu- 
ments. 
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to form the value of the function g by selecting the components of the sequence 
< 6i, > pointed to by the indexes ii, ...jii. 

It is clear, that index computability of h : Nat^ ^ Nat x Nat* may be 
reduced by traditional methods of the recursion theory to computability of a 
certain (partial recursive) function r : Nat — >■ Nat. 

We are ready now to give the main definition of this section. 

A function f : D ^ D is called naturally computable (with respect to 
given B and nat), if there is a code computable function g : Nat{B) ^ Nat{B) 
such that / = nat o g o denat. The class of all naturally computable functions is 
denoted by N atC omp{D , B , nat) . 

The relations between introduced notions of computable functions can be 
presented with the help of the following diagram of natural computability, in 
which double-headed arrows denote multi-valued functions. 



/ 

d: D 

nat 



d' : D 

j . 

denat 




{k,m) : h (fc', < il, ..., >) : 

Nat X Nat Nat x Nat* 



i 

n : Nat 



r 



n' : Nat 



Analysing this diagram we can conclude, that natural computability as a 
generalization (relativization) of enumeration computability. In fact, for i? = 0 
code computability reduces to partial recursive computability on iVat, and nat- 
ural computability reduces to enumeration computability (with respect to nat). 
Natural computability may be also used to define computability of polymor- 
phic functions. Therefore, the notions of code and natural computability defined 
above are quite rich. 
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We start investigation of natural computability with the following question: 
how strongly the class of naturally computable functions depends on specific 
features of the naturalization mapping? 

It turns out, that the class N atC omp{D , B , nat) is stable under “effective” 
transformations of nat. Thus, the situation is the same as for enumeration com- 
putability. More formally, we say that a naturalization mapping nat' : D — >■ 
Nat(B) is weaker than a naturalization mapping nat : D — >■ Nat(B) (denote 
nat' < nat), if there exists a code computable function cc : Nat{B) ^ Nat{B) 
such that nat' = nat o cc. The introduced relation is reflexive and transitive, but 
not antisymmetric. Thus, this relation is a preorder. 

Theorem 1. Let nat, nat' : D ^ Nat{B) be naturalization mappings such that 
nat' < nat. Then 

NatComp{D, B,nat') C NatComp{D,B,nat). 

Proof. Let /' G NatComp{D,B,nat'). Natural computability of /' is based 
on a certain code computable function g' such that /' = nat' o g' o denat' . 
From this follows that f' = (nat o cc) o g' o [nat o cc)“^ = nat o cco g' o cc~^ o 
nat~^ = nat o (cc o g' o cc~^) o denat. If cc~^ is code computable, then cc o 
g' o cc~^ is also code computable. Therefore, /' G N atC omp{D , B , nat) . But 
in general, cc~^ is not code computable. This difficulty can be overcome by 
constructing a code computable function g which simulates cc o g' o cc~^. To 
construct such a function we have first to consider index computable functions 
hcc and hg, on which computability of cc and g is based. Then, using these 
functions hcc and hg, we construct by conventional methods of the recursion 
theory an index computable function hg, which defines g. From this follows that 
/' G NatComp{D,B,nat). 

So, if two naturalization mappings nat and nat' are equivalent {nat < nat' 
and nat' < nat), then these mappings define the same class of naturally com- 
putable functions, i.e. NatComp{D,B,nat') = NatComp{D,B,nat). 

Having defined the notion of natural computability we can now construct 
algebraic representations of complete classes of naturally computable partial 
multi-valued functions for various data structures, which are considered as spe- 
cializations of nominative data. 



5 Complete Classes of Computable Partial Multi-valued 
Functions 

In this short paper we present without details only a few results describing 
complete classes of computable functions over simple subclasses of nominative 
data. 

We start with the simplest case. 
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5.1 Computability over Abstract Data 

Let D be an abstract set. It means that nothing is known about the structure 
of its elements. This treatment can be expressed by the naturalization mapping 
nat-a : D — >• Nat{D) such that nat-a{d) = {0,< d >) for every d G D. 

To define the complete class of naturally computable functions over D, we 
have to describe all index computable function of the type Nat^ ^ Nat x Nat*. 
It is easy to understand that under the naturalization mapping nat-a we need to 
know the results of index computable function only on the element (0,1). There 
are only three possible behaviours of an index computable function on (0,1): 

— to be undefined, 

— to yield (0,1), 

— or to make non-deterministic choice between being undefined and yielding 

( 0 , 1 ). 

These three cases induce the following functions of type D ^ D: 

— the everywhere undefined function und, 

— the identity function id, 

— the non-deterministic function und-id such that und-id{d) is undefined or is 
equal to d. 



Theorem 2. The complete class of naturally computable partial multi-valued 
functions over the abstract set D precisely coincides with the class of functions 
{und, id, und-id}. 

5.2 Computability over Named Data 

A class NAD{V, W) of named data is a special subclass of nominative data with 
single- valued naming and is defined inductively on the basis of the set of names 
V and the set of basic values W : 

— ii w G W, then w G N AD{V, W), 

— if v\,...,Vn are pairwise distinct names from V, d\,...,dn G N AD{V,W), 
then 

[v\ I— >■ d\, ..., Vn I— dn] G N AD{y, W). 

We can also describe the set NAD{V, W) by the recursive definition 

NAD{V, IT) = IT U (C 4 NAD{V, IT)), 

where A 4 i? is the set of finite single- valued mappings. 

The class of computable functions over NAD{V, IT) depends on the abstrac- 
tion level, on which V and IT are considered. Here we present only two cases 
determined by finite and countable sets of names. 
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Let V = {fo, be a finite set (m > 0), W be an abstract set. Then 

data of the set NAD{V, W) are called t^-finite IT-abstract named data. 

This understanding of NAD{V, W) can be presented by the naturalization 
mapping nat_fa : N AD{V,W) ^ Nat{W), which is defined inductively as fol- 
lows: 

— if d G W, then 

nat_fa{d) = (c(0, 0), < d >); 

- if d = di, d„], ii < ... <in,n> 0, 

nat_fa{dj) = {kj,< >), 1 < j < n, 

then 

natja{d) = {c{l, c{n, c{k[, ...c{k'^,0) ...))), < >), 



where fc' = c{ij,c{kj,lj)), 1 < j < n. 



Here c : Nat x Nat — >■ Nat is the Cantor’s pairing function. 

Having defined the naturalization mapping for N AD{V,W), we obtain the 
class NatComp{D,B,nat_fa) of all naturally computable functions over the 
class NAD{V, W). The algebraic description of this class is based on a certain 
algebra, which is called the BACON algebra (BAsic Composition Nominative 
algebra jH]). This algebra has the set of functions N AD(V,W) ^ N AD{V,W) 
as its carrier set, compositions o, V as its binary operations, parametric 
functions , f=>, n! {v G V) and a function choice as its null-ary operations. 
The class of all terms of this algebra is called the BACON language j^. It turns 
out that this language presents the class NatComp{D, B, nat_fa). 

Theorem 3. The complete class of naturally computable partial multi-valued 
functions over the set N AD(V,W) of V -finite W -abstract named data precisely 
coincides with the class of functions obtained by closure of the set of functions 
{=>Uo, ..., Uq!, ..., Um!, cdofce} under the set of compositions 

{o,*, V}. 

To prove the theorem, we first have to show, that BACON terms (programs) 
describe functions, which are naturally computable. This can be easily done in 
two steps. 

1. Prove that functions =>u, u=>, v\ {v G V) and choice are naturally 
computable. 

2. Prove that compositions o, *,V preserve natural computability of func- 
tions. 

After that, we have to prove that any function / G NatComp{D, B, nat-fa) 
can be presented by some BACON term. This proof consists of the following 
steps. 
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1. Represent Nat, Nat^, Nat* and Nat{W) within N AD{V,W). 

2. Represent by BACON terms all partial recursive functions, index com- 
putable functions and code computable functions. 

3. Represent by BACON terms the naturalization mapping nat_fa and the 
denaturalization mapping denat_fa. 

The details of these steps can be found in |^. 

At last, taking into account that / = nat^fa o g o denat-fa for some code 
computable function g : Nat{W) ^ Nat{W) we can conclude that / can be 
represented by some BACON term. This completes the proof of the theorem. 

The obtained result can be generalized for the following class of named data. 

Let V = {uq, Vi, ...} be an enumerable set, W be an abstract set {V C\W = 0). 
Since V is enumerable, any name from V can be recognised and generated. 
Therefore, elements of the set V will be used not only as names but also as basic 
values. In other words, we will consider the set of named data NAD{V, WUV). 
Such data are called R-enumerable IT-abstract named data. 

This understanding of NAD{V, WVJV) can be presented by the naturalization 
mapping nat.ea : N AD(V,W UV) ^ Nat{W), which is defined inductively as 
follows: 

— if d G W, then 

nat(d) = (c(0, 0), < d >); 

— if d G T, d = 'Cj, then 

nat{d) = (c(l, i), 0), i = 0, 1, ...; 

— if d = [vi^ !->■ di, ..., Vi^ !->■ dm], ii < ... < im, m>0, and 

nat{dj) = {kj,< bj^,...,bj^, >), j = l,...,m, 

then 

nat{d) = {c{m + 2,c{k[,...,c{k',^,0)...)),< >), 

where fc' = c{ij,c{kj,lj)), j = l,...,m. 

In order to describe the complete class over NAD{V, W U V), we should use 
the following additional functions. 

- Functions over V\ successor succy, predecessor predy and constant vq. 

- Equalities: =vq, = 0 . 

- Unary predicates: gU, GW. 

- Binary functions: as (naming), cn (denaming), ex (removal) and predicate 
ec (existence of named component), such that as{v,d) = =>u(d), cn{v,d) = 
v^{d), ex{v, d) = \v{d), ec{v, d) = v\{d) for any v GV, d G NAD{V, W U V). 

Theorem 4. The complete class of naturally computable partial multi-valued 
functions over the set N AD{V, WUV) of V- enumerable W -abstract named data 
precisely coincides with the class of functions obtained by closure of the set of 
functions {=>'Co; =>'Ci, GV, gW, vq, =vq, = 0 , succy, predy, as, cn, ex, ec, 
choice} under the set of compositions {o,*, V}. 
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5.3 Computability over Nominative Data 

In comparison with named data, nominative data allow multi-valued naming. To 
work efficiently with such data we have to consider a more specific abstraction 
level introducing equality on W. Nominative data of this level will be called W- 
equational data. We will consider here only finite nominative data. For such a 
class of nominative data a naturalization mapping should additionally represent 
in the code of the resulting natural data the information about all equalities 
between basic elements of the initial nominative data. The detail are described 
in [It) . 

To present computable functions we additionally use a subtraction function 
\ of nominative data and binary summation composition U. In this case the 
equality on W is derivable. For the class of Wfinite VF-equational nominative 
data we can formulate the following result. 

Theorem 5. The complete class of naturally computable partial multi-valued 
functions over the set of V-finite W -equational nominative data precisely co- 
incides with the class of functions obtained by closure of the set of functions 
{=>uo,..., vq^,..., Vef.,..., Vmh choicc, \} Under the set of compo- 

sitions {o, *, U}. 

5.4 Computability over Sequences 

Traditional data structures may be considered as concretizations of nominative 
data. Here we present the completeness result for functions over sequences. 

Let B be an abstract set and Seq{B) be the set of all sequences, hierarchically 
constructed from elements of B. The set Seq{B) may be defined by recursive 
definition Seq{B) = H U Seq{B)* . 

The structure Seq{B) has been investigated in different works. We shall use 
the notations of m- Four new functions are introduced: first, tail, apndl, 
is-atom. Also, we need a composition, called construction: 

[f,9]{d) =< f{d), g{d) > . 



Theorem 6. The complete class of naturally computable partial multi-valued 
functions over the set Seq{B) precisely coincides with the class of functions 
obtained by closure of the set of functions {first, tail, apndl, is-atom, choice} 
under the set of compositions {o, *, [ ]}. 

In a similar way we can also generalize the completeness results for compo- 
sitional databases presented in m- 

6 Conclusion 

In this paper we defined the notion of natural computability for partial multi- 
valued functions, which represent semantics of non-deterministic programs. This 
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computability is a special abstract computability, that satisfy the main require- 
ments formulated by A.P. Ershov. The complete classes of naturally computable 
functions are described for simple cases of nominative data. The proposed tech- 
nique can be used for more rich data structures. The notion of natural com- 
putability forms a base for the notion of determinant computability of composi- 
tions. The obtained results can be used to study computational completeness of 
programming, specification and database query languages of various abstraction 
levels. 
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Abstract. We propose a method to analyse the program space complex- 
ity, based on termination orderings. This method can be implemented 
to certify the runspace of programs. We demonstrate that the class of 
functions computed by first order functional programs over free algebras 
which terminate by Lexicographic Path Ordering and admit a polyno- 
mial quasi-interpretation, is exactly the class of functions computable in 
polynomial space. 



1 Introduction 

Motivations. There are several motivations to develop automatic program com- 
plexity analysis: 

1. The control of the resources consumed by programs is a necessity, in software 
development. 

2. There is a growing interest in program resource certifications. For example, 
Benzinger |2] has implemented a prototype to certify the time complexity 
of programs extracted from Nuprl [B]. Various systems have been defined 
to control resources in functional languages, see Weirich and Crary [7] and 
Hofmann m- 

3. Our approach is based on well-known termination orderings, used in term 
rewriting systems, which are easily implemented. 

4. The study of program complexity is of a different nature compared to pro- 
gram verification or termination. It is not enough to know what is computed, 
we have to know how it is performed. So, it gives rise to interesting questions 
whose answers might belong to a theory of feasible algorithms which is not 
yet well established. 

Our Results. We consider first order functional programs over any kind of con- 
structors, which terminate by Lexical Path Ordering (LPO). We demonstrate 
that the class of functions which are computed by LPO-programs admitting poly- 
nomially bounded quasi-interpretations, is exactly the class of functions which 
are computed in polynomial space. (See Section 13.21 for the exact statement.) 
This resource analysis can be partialy automatized. Indeed, Krishnamoorthy 
and Narendran in m have proved that termination by LPO is NP-complete. To 
find a quasi-interpretation is not too difficult in general, because the program 
denotation turns out to be a good candidate. 
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Complexity and Termination Orderings. Termination orderings give rise to in- 
teresting theoretical questions concerning the classes of functions for which they 
provide termination proofs. Weiermann |23] has shown that LPO characterizes 
the multiple recursive functions and Hofbauer [TOj has shown that Multiset Path 
Ordering (MPO) gives rise to a characterization of primitive recursive functions. 
While both of these contain functions which are highly unfeasible, the fact re- 
mains that many feasible algorithms can be successfully treated using one or 
both. Quasi-interpretations allows us to tame the complexity of treated algo- 
rithms. Indeed, it has been established m that functions computed by pro- 
grams terminating by MPO and admitting a polynomial quasi-interpretation 
are exactly the polynomial time computable functions. This last result might be 
compared with the one of Hofbauer. Analogously, the result presented in this 
paper might be compared with Weiermann’s one. 

Other Related Characterizations of Poly-Space. There are several characteriza- 
tions of PSPACE in Finite Model Theory, and we refer to Immerman’s book m 
for a complete presentation. A priori. Finite Model Theory approach is not rel- 
evant from the point of view of programming languages because computational 
domains are infinite. But recently, Jones m has showed that polynomial space 
languages are characterized by mean of read-only functional programs. He has 
observed a closed relationship with a characterization of Goerdt [9] . 

On infinite computational domains, characterizations of complexity classes 
go back to Cobham’s seminal work [5]. The set of polynomial space computable 
functions has been identified by Thompson |22) . Those characterizations are 
based on bounded recursions. Hence, they do not directly study algorithms and 
so they are not relevant to automatic complexity analysis. 

Lastly, from the works of Bellantoni and Cook |T] and of Leivant |18], purely 
syntactic characterizations of polynomial space computable functions were ob- 
tained in [T9l20l . The underlying principle is the concept of ramified recursion. 
From the point of view of automatic complexity analysis, the main interest of 
this approach is that we have syntactic criteria to determine the complexity of 
a program. However, a lot of algorithms are ruled out. Several solutions have 
been proposed to enlarge the class of algorithms captured. Hofmann m has pro- 
posed a type system with modalities to deal with non-size increasing functions, 
e.g. the functions max and min. Another solution is to introduce a ramified ver- 
sion of termination orderings MPO jSDI, which delineates polynomial time and 
polynomial space computable functions. 

2 First Order Functional Programming 

Throughout the following discussion, we consider three disjoint sets X,J-,C of 
variables, function symbols and constructors. 
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2.1 Syntax of Programs 

Definition 1. The sets of terms, patterns and function rules are defined in the 
following way: 



(Constructor terms) 
(Ground terms) 
(terms) 

(patterns) 

(rules) 



T{C) 5 u 
T{C,T) 9 s 
T{C,T,X) 9 t 
P B p 
V^d 



=C I c('Ui, . . . , Uji) 

=c I c(si,... ,s„) I /(si,... ,s„) 

=C I a: I c(ti, ... ,tn) I /(tl, ... ,tn) 
=c I a: I c{pi,... ,Pn) 

,Pn) t 



where x £ X , f G (F , and c £ cfl. The size |t| of a term t is the number of 
symbols in t. 

Definition 2. A program £{main) is a set £ ofP-rules such that for each rule 
f{pi, ■ ■ ■ ,Pn) t of £, each variable in t appears also in some pattern pi. All 
along the paper, we assume that the set of rules is implicit and we just write 
main to denote the program. 

Example 1. The following program is intended to compute the Ackermann’s 
function. Take the set of constructors to be C = {0,S}. We won’t explicitly 
note the arity of symbols, as it is implicitly given by the rules. 



Ack(0, n) — S(n) 

Ack(S(77i), 0) — Ack(m, S(0)) 
Ack(S(77i), S(n)) — >■ Ack(m, Ack{S{m),n)) 



2.2 Semantics 

The signature CU (F and the set £ of rules induce a rewrite system which brings 
us the operational semantics. We recall briefly some vocabulary of rewriting 
theories. For further details, one might consult Dershowitz and Jouannaud’s 
survey [H] from which we take the notations. The rewriting relation — >■ induced 
by a program main is defined as follows t — >■ s if s is obtained from t by applying 
one of the rules of £. The relation A is the reflexive-transitive closure of — >■. 

I * . . 

Lastly, t— means that t— >-s and s is in normal form, i.e. no other rule may be 
applied. A ground (resp. constructor) substitution is a substitution from X to 
nC, P) (resp. nC)). 

We now give the semantics of confluent programs, that is programs for which 
the associated rewrite system is confluent. The domain of interpretation is the 
constructor algebra T(C). 

Definition 3. Let main be a confluent program. The function computed by main 
is a partial function : 7”(C)"' — >■ T(C) where n is the arity of main. For 

all Ui G T{C), \main\{ui, . . . ,Un) = v iff main{ui, . . . ,rt„)— with v G T{C). 
Note that due to the form of the rules a constructor term is a normal form ; as 
the program is confluent, it is uniquely defined. Otherwise, that is if there is no 
such normal form, |main|(ui, . . . ,u„) is undefined. 

We shall use type writer font for function symbol and bold face font for constructors. 



1 
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3 LPO and Quasi-Interpretations 

3.1 Lexicographic Path Ordering 

Termination orderings are widely used to prove the termination of term rewrit- 
ing systems. The Lexicographic Path Ordering (LPO) is one of them, it was 
introduced by Kamin and Levy m- We briefly describe it, together with some 
basic properties we shall use later on. 

Definition 4. Let -< be a term ordering. We note its lexicographic extension. 
A precedence (strict precedence -<yr) is a quasi- ordering (ordering) on the 
set T of function symbols. Lt is canonically extended onCUJ- by saying that con- 
structors are smaller than functions. Given such a precedence, the lexicographic 
path ordering -<ipo is defined recursively by the rules: 



s<ipoU Si <ipo f{ti, . . . ,tn) g f 

/e^UC <?e^UC 



s -^Ipo /(• • • ! L , . . . ) 



g{si 5 • • • ; Sm ) ~^lpo f(j^l ? • • • 5 ^n) 



(Sl, . . . , Sn) ^Ipo ■ ■ ■ ; f 9 ^3 ^Ipo f{^li ■ ■ ■ i ^n) 

,Sn) -<l po ,G) 



Definition 5. < is the usual subterm ordering. That is s < /(ti, . . . */ 

only if s = ti or s <iti for some 1 < i < n. 

Lemma 1. Let t and s be constructor terms, s -<ipo t implies |s| < |t|. 

Example 2. One can verify that the Ackermann’s function of example [l] termi- 
nates by LPO. 



3.2 Polynomial Quasi-Interpretation 

Definition 6. Let f € iFljC be either a function symbol or a constructor of 
arity n. A quasi-interpretation of f is a mapping (|/|) : N” — >■ N which satisfies 
(i) (/[) is (not necessarily strictly) increasing with respect to each argument, (ii) 
(|/|)(Ai,... ,Xn) > Xi, for all 1 < i < n, (Hi) (/[) > 0 for each 0-ary symbol 
f GEUC. 

We extend a quasi-interpretation (— [) to terms canonically: (/(ti, . . . ,tn)|) = 

d/Kd^iDr- • 

Definition 7. (|— ) is a quasi-interpretation of a program main if for each rule 
I ^ r G £{main) and for each closed substitution a, drcr) < d^cr). 

Lemma 2. Lft and t' are two terms such that t — >■ t' , then dt) > d^^D- 

Definition 8. A program main admits a polynomial quasi-interpretation (— [), if 
d~ ) is bounded by a polynomial. 

A polynomial quasi-interpretation is said to be of kind 0 if for each construc- 
tor c, dc)(Ai, . . . , Xn) = 0 - 1 - X^r=i f^’’’ some constant o > 0. 
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Remark 1. Quasi-interpretations are not sufficient to prove program termina- 
tion. Indeed, the rule i{x) — >■ f(a;) admits a quasi-interpretation but doesn’t 
terminate. 

Unlike quasi-interpretation, a program interpretation satisfies to extra condi- 
tions: (i) d/D(Xi,... ,Xn) > Xi, (ii) l\ra\) < Programs admitting an inter- 
pretation terminate. This sort of termination proof, by polynomial interpreta- 
tions, was introduced by Lankford [13 . Bonfante, Cichon, Marion and Touzet |3] 
proved that programs admitting interpretation of kind 0 are computable in poly- 
nomial time. 

Definition 9. A LPO-program is a program that terminates by LPO. 

A -program is a LPO-program that admits a quasi-interpretation 

of kind 0 . 

Theorem 1 (Main Result). The set of functions computed by - 

programs is exactly the set of funtions computable in polynomial space. 

Proof. It is a consequence of Theorem |2] and Theorem 2] 

Example 3. 

1 . The Ackermann’s function of example [T] doesn’t admit a polynomial quasi- 
interpretation because |Ack] is not polynomially bounded. 

2. The Quantified Boolean Formula (QBF) is the problem of the validity of 
a boolean formula with quantifiers over propositional variables. It is well- 
known to be PSPACE complete. Wlog, we restrict formulae to V, 3. It can 
be solved by the following rules: 



not(tt) -A ff 
not(ff) tt 
or(tt, a;) — tt 
or(ff, x) —>■ X 



0 = 0 -)> tt 

S(a:) = 0 ^ flf 
0 = S(y) ^ flf 
S(x) = S(y) x = y 



main(^) — >■ ver(0, nil) 
in(x, nil) -A ff 

in(a;, cons(a, 1)) — or{x = a, in(cc, 1)) 

In the next function, t is the set of variables whose value is tt. 



ver(Var(a;), t) -A in(x,t) 
ver{Or{4>i,(j)2),t) ^ or(ver(0i,t), ver((/) 2 ,t)) 
ver(Not((^), t) — ^ not(ver(()), t)) 
ver(Exists(n, (?!)), t) — or(ver(<(), cons(n, t)), ver(</), t)) 



These rules are ordered by LPO by putting {not, or, _=_} -<j7 in -<j7 ver 
main. 

They admit the following quasi-interpretations: 

— (|c|)(Ai, . . . , Xn) = 13- n-ary constructor, 

— dver|)(^, T) = <P -\- T, (|main[)(<?) = ^ 3- 1, 

— (|f |)(Ai, . . . , Xn) = max"^;^ Xi, for the other function symbols. 
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4 LPO^°^^^°^-Programs Are Pspace Computable 

Definition 10 . A state is a tuple ■ ■ ■ , tn) where f is a function symbol of 

arity n and ti, . . . ,tn ore constructor terms. 

State{main) is the set of all states built from the symbols of a program main. 
State^{main) = {{f,t\,-.. An) G State(main) / \ti\ < A}. Intutively, a state 
represents a recursive call in the evaluation process. 

Definition 11. Let main be a -program, r]i = {f,ti, . . . , tn) and rj 2 = 

{g,si,... ,Sm) be two states of State{main). A transition is a triplet rji 'A rj 2 
such that: 

(i) e= f{pi,... ,Pn) ~^t 

(ii) there is a substitution a such that piCr = ti for all 1 < i < n 
(Hi) there is a subterm g{u \, . . . , Um) ^ t such that Uia^Si for all I < i < n. 

Transition(main) is the set of all transitions between the elements of 
State(main) . 

A- is the reflexive transitive closure ofUe^e 

Definition 12. Let £{main) be a -program and {f,ti,... ,tn) be a 

state (i.e. {f,ti,... ,t„) G State{main) ) . A {f,ti,... ,tn)-call tree r is defined 
as follows: 

— The root of t is {f,t\, . . . ,tn). 

— For each node rji, the children of rji is exactly the set of states {772 G 

State{main) / 772 G Transition{main)} where e is a given equation 

of£. 

CT{{f, ti, . . . , tn)) is the set of all {f,ti, . . . , t„)-call trees. 

CT^((/,ti, . . . ,tn)) = {r G CT((/,ti, . . . ,tn)) / yr]eT,rie State^ (main)} 

Example 4- The (unique) (Ack, S(0), S(0))-call tree of CT((Ack, S(0), S(0))) is: 




Lemma 3. Let main be a LPO-program, a be the number of function symbols 
in main and d be the maximal arity of a function symbol. The following facts 
hold for all r G CT^{{f, ti, . . . , t„)) : 

1- If if Ai,--- An) {g,si,... ,Sm) then (a) g f or (b) g f and 

(si, . . . , Sm) ^Ipo {tl, ■ ■ ■ , tn). 
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2. If (/, ti, . . . , (g, si, . . . , Sm) in r and g / then the number of states 

between {f,ti, . . . , and {g,si, . . . , Sm) is bounded by A‘^. 

3. The length of each branch of t is bounded by a x A‘^. 

Proof. 

1. Because the rules of the program decrease for LPO. 

2. Let (h, ui,... ,Up) be a child of ,tn)- As ti and Uj are con- 

structor terms, due to first point of the current lemma and lemma [T] we 
have ,|Mp|) <* ,|tn|)- Since the size of each component is 

bounded by A, the length of the decreasing chain is bounded by A'^. 

3. In each branch, there are at most A‘^ states whose function symbols have the 
same precedence, then A‘^ states whose function symbol have the precedence 
immediatly below, and so on. As there are only a function symbols the length 
of the branch is bounded by a x 



Lemma 4. Let main be a -program, f be a function symbol and 

ti, . . . ,tn be constructor terms. CT{f, t\, . . . , tn) = 4n)|) . . . , . 

Proof. Let t G CT(f , ti, . . . , and (g, si, . . . , Sm) be a state in r. As Si is a 
constructor term, |si| < (|siD < (|g(si, . . . , Sm)D < df (ti, • ■ • , tn)D because of the 
definition of quasi-interpretations. 



Lemma 5. Given a term t € T{C), the following holds: d^D < c.\t\ for some 
constant c. As a corollary, we have l\main{ti, . . . ,tn)D ^ P(max”^j^ |ti|) for some 
polynomial P. 



Theorem 2. Let main be a -program. For each constructor terms 

t\, . . . ,tn, the space used by a call by value interpreter to compute 
mainlfi, . . . ,tn) is bounded by a polynomial in maXi{\ti\}. Such an interpreter 
is described in annex. 

Proof. Put A = dmain(ti, . . . , <„)|). 

The interpreter only needs to store the call stack of each recursive call and 
the intermediate terms (e^, b) of the computation. The size of and b are both 
bounded by A. Note that the computation can be followed on a (main, ti, . . . , tn) 
call-tree. Each recursive call corresponds a transition on the call-tree. So, the 
maximal depth of the stack corresponds to the maximal length of the branch 
in a call tree of (7T(main,<i, . . . ,tn) = CT"^(main,ti, . . . ,t„). So it is bounded 
by a X A"^ (see Lemma EJS)). The values stored in the stack are states; as a 
consequence, the size of each of them is bounded bydxA-fO(l). 

Therefore, the space used by the interpreter is bounded by a x d x A^~^^ -\- 
A -\- 0(1), and A is a polynomial in the size of maxi{|ti|} by LemmaEl 
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5 Parallel Register Machines over Words 

We present here a restriction of Parallel Register Machines introduced in [T^ . 
They are an adaptation of the alternating Turing machine. Chandra, Kozen and 
Stockmeyer have demonstrated that the set of functions that alternating Turing 
machines computes in polynomial time is exactly the state of polynomial space 
computable functions. 

Definition 13. W = T({0\ e°}). N = T({s\o°}). 

Note thatW (resp. is isomorphic to {0, 1}* (resp. natural numbers), both 
sets are used indiferently in the rest of the section. 

Definition 14. A Parallel Register Machine (PRM) over the word algebra W 
consists in: 

1. a finite set S = {sqj si, • • ■ j Sfc} of states, including a distinct state begin. 

2. a finite list II = {tti, . . . ,TTm} of registers; we write output for Reg- 
isters will only store values in W; 

3. an ordering < on W: £ < y, 0{x) ◄ l{y), i{x) ◄ i{y) if and only if x ◄ y. 

4-. a function com mapping states to commands which are: 

[Succ{tt' = i{Tr), s')], [Pred{n' — s')], [Branch^n, s' , s")], 

[Forkmin{s',s")], [Forkmaxls' , s")], [En^. 

A configuration of a PRM M is given by a pair (s, F) where s G S and F is 
a function II — >■ W. We note [ui , . . . , Um] for the function which maps tt^ i— >■ Ui 
and {iTi G- a}[ui, . . . ,Um] denotes [ui, . . . ,Ui-i,a,Ui+i, . . . ,Um]- 
Definition 15. Given M as above we define a semantic partial- function aval : 
N X S X W™ I— >■ W, that maps the result of the machine in a “time bound” given 
by the first argument. 

— eval(0,s,F) is undefined. 

— If com{s) is Succ(tt' = i(7r),s') then evalft -\- l,s,F) = eval(t, s' ,{ tt' g- 
i(7r)}T'). Note that on the right of the left arrow, tt denotes the content of 
the register; 

— If com{s) is Pred^ir' = p(7r),s')], then eval{t -\- l,s,F) — eval{t, s' , {tt' g- 

p{t^)}F); 

— If com(s) is Branch^TT, s' , s") then eval(t -\- 1, s, F) = eval(t,r, F), where 
r = s' if TT = 0{w) and r = s" if tt = l{w); 

— If com{s) is Forkjj,in{s' , s") 

then evalft + 1, s, F) = mhi.^(eval(t, s' , F), eval(t, s" , F)); 

— Ifcom{s) is Fork^axis' , s") 

then evalft + 1, s, F) = max.^{eval(t, s' , F), evalft, s" , F)); 

— If com{s) is End then eval{t -\- 1, s, F) = A(output). 

Definition 16. Given a function T : N ^ N, we say that the PRM M computes 
f : -G W in time T (or equivalently that f is T-computable) if for all 

{wi, . . . , Wk) G W^, we have 

hj 

enal(r(max|wi|), BEGIN, ,Wfc,e,... ,e]) = f{wi,... ,Wk) 

i—1 

Theorem 3 (Chandra & al [3IJ). Let / : W — >■ W. / is computable in poly- 
nomial space iff f is PRM- computable in polynomial time. 
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5.1 Simulation of PRMs by LPO^°* 2 /(o)_pj,Qgj.^jj^g 

The simulation of PRM is done simply by following the rules of the operational 
semantics of PRM we gave above. In particular, the first argument of eval 
represents a clock. 

Lemma 6 (Plug and Play Lemma). Let / : W — )> W &e a T-time PRM- 
computable function, then, the function f is computable by an . 

/' : N X W ^ W 

(n,w)H>/(w) ifn>T{\w\) 

(n, u>) I— >■ _L otherwise 

Proof. Let the set of constructors be C = {0, l,s,o, e} U 5 where S is the set 
of states. We let the rules in appendix IB] Simply, let’s say that the functions 
symbols are: min, max corresponding to min.^,max.^, eval which simulate the 
rules of the operational semantics and fb We develop here two rules for eval. 

- Eval(s(f),s,7ri,... ,7T„) ^ Eval(t, s', tti, . . . , i(7Tfc), . . . , 7 t„) if 
COm{s) = SuCc(7Tj = i(7Tfe),s'), 

- Eval(s(f), s, TTi, . . . ,7Tm) min(Eval(t, s',7Ti, . . . , tt^), Eval(t, s", tti, ..., 

TTm)) if com{s) = Forkmin(s',s") 



Take the precedence {min, max} -<jr Eval, these rules decrease according 
to LPO because the time bound decrease. They admit the following quasi- 
interpretation: 

(e|) = l (0)(W) = Y:-E1 (|min)(W, W') = max(W,IT') 

(o) = 1 (1)(X) = X -E 1 (max)(W, W) = max(W, W) 

H(X) = X+1 



Vs G S, (s) = 1 (|Eval[)(r, S', Til, . . . ,11^ = maxjili, . . . ,7T„} x T -|- S 

Now, the function f' is defined by f'(n, w) — ^ Eval(n, begin, w,e, . . . , e). It is 
routine to check that /' = |f']. This rule decreases by LPO by taking f' Eval. 
There is also a quasi-interpretation for the rule: (f'[)(7V, X) = N x X -|- 1. 

Lemma 7. Given rc G W and a polynomial P, the function w G W i— >■ P(|ui|) 
is computable by a LPO^°^y^^^ -program. The proof is given in the appendix. 



Theorem 4. A polynomial time PRM computable function f can be computed 
by an LPO^°‘y^°^ -program. 

Proof. Follows from Lemma El and Lemma [7] 
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A Interpreter for LPO^°*^^°^-Programs 

A space-economical interpreter: 

function eval(f , ti, . . . ,t„) 

begin 

let e = f(pi, . . . ,pn) -f t 
let a such that piO = ti 
let Co = to 
let z = 0 

foreach g(si,... ,s^) < e* A G T(C),j G {l,..,m} do 
b= eval(g, si,... ,Sm) 

Ci+i = ei{g(si, . . . , Sm) f- b} 

i = i-\- 1 

return 

end. 

where ei{g(si,... ,Sm) ^ b} denotes the term Ci where each occurence of 
g(si, . . . , Sm) has been replaced by b. 

B Simulation of PRM by LPO^°*^*^“^-Programs 

One follows the operational semantics of PRMs. 

min(e,'u;) — >■ e max(e,zc) — >■ w 

min(z(;, e) — >■ e max(zz;, e) ^ w 

min(0(zc), l('u;')) — l 0(zc) max(0(z(;), l('u;')) — >■ l(tc') 

min(l(z<;), 0(ii;')) — 1 O(zc') max(l(z(;), 0('u;')) — 1 l(tu) 

min(i(zc), i(ii;')) —1 i(min(z(;, zc')) max(i('u;), i(ii;')) -G i(max(zc, zc')) 

with i G {0, 1}. We have Jniin] = min.^ and |max| = max.^. 

(a) Eval(s(t),s,7Ti,... ,Trm) Eval(t, s', tti, . . . , 7r^_i, i(7Tfc), tt^-i-i, . . . ,7t„) 
if COm{s) = SuCc(7Tj = i(7Tfc),s'), 

(b) Eval(s(t),s,7Ti,... ,i(7r'),... ,Tim) 

-1 Eval(t, s',7Ti, . . . ,7 t',... ,i(7r'),... ,TTm) 
if com{s) = Pred(7Tfc = p(7Tj), s'), 
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(c) Eval(s(t),s,7Ti,... ,7rj_i,i(7rj),7Tj+i, . . . ,7r„) ^ Eva.l{t,r,ni, . . . ,7r^) 
if com(s) = Branch(7Tj , s', s") where r = s' if i = 0 and r = s" if i = 1, 

(d) Eval(s(f),s,7ri,... ,7r„) 

->min(Eval(t, s',7Ti,... , tt^), Eval(f, s", tti, . . . 
if com{s) = Forkmin(s', s") 

(e) Eval(s(f),s,7ri,... ,TTm) 

— > max(Eval(f, s', 7Ti, . . . , tt^), Eval(t, s", tti, . . . ,TTm)) 
if com(s) = Forkmax(s', s") 

(f) Eval(s(f),S,7ri,... ,7T„i) -)> 7Tm 
if com(s) = End 

B.l Computation of Polynomials by LPO^°*^(°^-Programs 

Each polynomials can be computed with a combination of add and mult. 

add(o, y) —>■ y mult(o, y) —>■ <> 

add(s(x),y) — ^ s(add(x, y)) mult(s(x), y) — ^ add(y, mult(x, y)) 

These functions are clearly ordered by LPO by putting add mult. And 
they admit the quasi-interpretations: 

^add[)(A,y) = A-hF 
^multD(A,y) = A X F 



Remark 2. The interpretation of a polynomial correponds to its semantics. 
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Abstract. We investigate the concept of generalised computability of 
operators and functionals defined on the set of continuous functions, 
firstly introduced in (9]. By working in the reals, with equality and with- 
out equality, we study properties of generalised computable operators 
and functionals. Also we propose interesting applications to formalisa- 
tion of hybrid systems. We obtain some class of hybrid systems, which 
trajectories are computable in the sense of computable analysis. 



1 Introduction 

Computability theories on particular and general classes of structures address 
central concerns in mathematics and computer science. The concept of gener- 
alised computability is closely related to definability theory investigated in [3]. 
This theory has many uses in computer science and mathematics because it 
can be applied to analyse computation on abstract structure, in particularly, 
on the real numbers or on the class of continuous functions. The main aim of 
our paper is to study properties of operators and functionals considering their 
generalised computability relative either to the ordered reals with equality, or 
to the strictly ordered real field. Note that generalised computability related to 
the strictly ordered real field is equivalent to computability in computable anal- 
ysis in that they define the same class of computable real-valued functions and 
functionals. We prove that any continuous operator is generalised computable 
in the language with equality if and only it is generalised computable in the 
language without equality. As a direct corollary we obtain that each continu- 
ous generalised computable with equality operator is computable in the sense of 
computable analysis. This paper is structured as follows. In Section 2, we give 
basic definitions and tools. We study properties of operators and functionals 
considering their generalised computability in the language with equality and in 

* This research was supported in part by the RFBR (grants N 99-01-00485, N 00-01- 
00810) and by the Siberian Branch of RAS (a grant for young researchers, 2000) 
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the language without equality. In Section 3 we present some application of the 
proposed model of computation to specification of hybrid systems. In the recent 
time, attention to the problems of exact mathematical formalisation of complex 
systems such as hybrid systems is constantly raised. By a hybrid system we 
mean a network of digital and analog devices interacting at discrete times. An 
important characteristic of hybrid systems is that they incorporate both contin- 
uous components, usually called plants, as well as digital components, i.e. digital 
computers, sensors and actuators controlled by programs. These programs are 
designed to select, control, and supervise the behaviour of the continuous compo- 
nents. Modelling, design, and investigation of behaviours of hybrid systems have 
recently become active areas of research in computer science (for example see |51 
HIIII2IIH]). The main subject of our investigation is behaviour of the continuous 
components. In the set of all possible trajectories of the plant was called 
as a performance specification. Based on the proposed model of computation 
we introduce logical formalisation of hybrid systems in which the trajectories 
of the continuous components (the performance specification) are presented by 
computable functionals. 

2 Generalised Computability 

Throughout the article we consider two models of the real numbers, 

X 

< M, (Ti >^< M, 0, 1, -b, •, <, -X, - > 
is the model of the reals without equality, and 

< M, (72 H, 0, 1, -b, •, <> 

is the model of the reals with equality. Below if statements concern languages 
a I and a 2 we will write a for a language. 

Denote T >2 = {z ■ 2~^\z S n S IM}. Let us use f to denote ri, . . . , r^. 

To recall the notion of generalised computability, let us construct the set 
of hereditarily finite sets HF(M) over a model M. This structure is rather well 
studied in the theory of admissible sets and permits us to define the natural 
numbers and to code and store information via formulas. Let M be a model of a 
language a whose carrier set is M. We construct the set of hereditarily finite sets, 
HF(M) = UnGo;Sn(M), where Sq(M) ^ M, S„+i(M) ^ iP^(S„(M)) U S„(M), 
where n G uj and for every set B, Vui{B) is the set of all finite subsets of B. 

We define HF(M) ^ (HF(M), M, cr, 0 hf(m)j Shf(m)) > where the unary 
predicate 0 singles out the empty set and the binary predicate symbol Ghf(m) 
has the set-theoretic interpretation. 

Below we will consider M ^ IR, cr* = cti U {g, 0} named the language 
without equality and ctJ = (72 U {g, 0} named the language with equality. Below 
if statements concern both languages crj and crj we will write a* for a language. 

To introduce the notions of terms and atomic formulas we use variables of 
two sorts. Variables of the first sort range over IR and variables of the second 
sort range over HF(IR). 
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The terms in the language af are defined inductively by: 1. the constant 
symbols 0 and 1 are terms; 2. the variables of the first sort are terms; 3. if ti,t 2 
are terms then ti + t 2 , ■ t 2 , —ti, y are terms. The notions of a term in the 

language ctJ can be given in a similar way. 

The following formulas in the language are atomic: ti < t2, t € s and 
Si S S 2 where ti,t2,t are terms and Si,S 2 are variables of the second sort. The 
following formulas in the language crj atomic: ti < t 2 , t G s, s± S S 2 where 
ti,t.2,t are terms and si,S 2 are variables of the second sort. 

The set of AQ-formulas in the language a* is the closure of the set 
of atomic formulas in the language a* under A, V, (3x S s) and (Vx S s), where 
(3x € s) ip denotes 3 x{x € s A ip) and (Vx € s) p denotes Vx(x € s ^ p) and s 
is any variable of second type. The language cti is the language of strictly ordered 
real field, so the predicate < occurs positively in Z\o-formulas in the language 

CTl . 

The set of S -formulas in the language a* is the closure of the set of Aq 
formulas in the language a* under A, V, (3x G s) , (Vx G s) , and 3. The natural 
numbers 0, 1, . . . are identified with 0, {0,{0}},...so that, in particular, n + 1 = 
nU {n} and the set is a subset of HF(IR). 

Definition 1 . A relation B C ]R” is E-definable in a* , if there exists a S- 
formula <?(x) in the language a* such that x G B HF(IR) |= ^(x). A function 
is E-definable if its graph is E-definable. 

Note that the set IR is Z\o-definable in both the languages al and cr|. This 
fact makes HF(IR) a suitable domain for studying relations in M" and functions 
from M"' to IR where n G w. For properties of T'-definable relations in IR" we 
refer to |3I6|I . 

Without loss of generality we consider the set of continuous functions defined on 
the compact interval [0, 1]. To introduce generalised computability of operators 
and functionals we extend ct* and by two 3-ary predicates U\ and C/ 2 . 

Definition 2 . Let pi{Ui,U2,xi,X2,c), p2{Ui,U2,xi,X2,c) be formulas of ex- 
tended language crj (ctJ/ We suppose that Ui, U2 occur positively in p\, p2 and 
the predicates U\, U2 define open sets in IR^. The formulas pi, p2 are said to 
satisfy joint continuity property if the following formulas are valid in HF(IR). 

1 . VX1VX2VX3VX4VZ ((Xi < X3) A (X4 < X2) A Pi{Ui,U2, Xi,X2,z)) -A 
Pi{Ui,U2,X3,X4,z), for i = 1,2 

2 . VxiVx 2 VcVz((z < c) A <^i(C/i, C/ 2 , xi, X 2 , c)) pi{Ui,U2,xi,X2, z), 

3 . VxiVx 2 VcVz((z > c) A <p 2 (C/i, C/ 2 , xi, X 2 , c)) (^ 2 (C/i, C/ 2 , xi, X 2 , z), 

4. VX1VX2VX3VZ {piiJJi, C/2, Xi, X2, z) A PiifJi, c/2, X2, X3, z)) -A 
Ti{Ui,U2,Xi,X3,z), for i = 1,2, 

5. {'iyiiy23z'iziiz2{Ui{yi,y2, zi) A U 2 {yi,y 2 ,zi) -A {zi < z < Z 2 ))) -t 
(VxiVx23cVciVc2(v?i(C/i, C/ 2 , xi, X 2 , ci) A p 2 {Ui, C/ 2 , xi, X 2 , C 2 ) -t 

(ci < c < C2))). 
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Definition 3. A partial operator F : C[0, 1] — >■ C[0, 1] is said to be shared 
by two S-formulas <p\ and ip 2 in the language a* if the following assertions 
hold. If F{u) = h then ^ -o- HF(IR) ^ C/ 2 , Xi, 2 : 2 , z) and 

^\[xi,x-,] <z-n- HF(IR) ^ ip 2 {Ui,U 2 ,xi,X 2 ,z), where Ui{xi,X 2 ,c) ^ M|[a:i,x2] > 
c,U 2 {xi,X 2 ,c) ^ u\i^xx,x 2 \ < c and U\, U 2 occur positively in ipi, ip 2 - 

Definition 4. A partial operator F : C[0, 1] — >■ Cp, 1] is said to be generalised 
computable in the language a* , if F is shared by two E-formulas in the language 
a* which satisfy the joint continuity property. 

Definition 5. A partial functional F : C'[0, 1] x [0, 1] — )> IR said to be gener- 
alised computable in the language a*, if there exists an operator F* : C[0, 1] — >■ 
C[0, 1] generalised computable in the language a* such that F{f,x) = F*{f)(x). 

Definition 6. A partial functional F : (7[0, 1] x IR — >■ IR is said to be generalised 
computable in the language a*, if there exists an effective sequence {Fffjn^ui of 
operators generalised computable in the language a* of the types F* : C[0, 1] — >■ 
C[—n,n] such that F{f,x) = y Vn (— n < x < n — >■ F*{f){x) = y) . 

Proposition 1. A partial functional F : C[0, 1] x IR — > IR is generalised com- 
putable in the language without equality if and only if it is computable in the 
sense of computable analysis. 

Proof. See [9I17| . 

Now we propose the main theorem which connects generalised computabilities 
in the various languages. 

Theorem 1. A continuous total operator F : C[0, 1] — >■ C[0, 1] is generalised 
computable in the language with equality if and only if it is generalised computable 
in the language without equality. 

Proposition 2. Let F : C[0, 1] x IR — >■ IR 6e a continuous total functional. The 
functional F is generalised computable in the language with equality if and only 
if it is generalised computable in the language without equality. 

Corollary 1. Let F : C[0, 1] x IR — > IR be a continuous total functional. The 
functional F is generalised computable if and only if F is computable in the sense 
of computable analysis. 

Now we point attention to a useful recursion scheme, which permits us to describe 
the behaviour of complex systems such as hybrid systems. 

Let F : C[0, 1] x C[0, 1] x IR ^ IR and G : G[0, 1] x [0, 1] ^ IR be 
generalised computable in the language with equality functionals. Then F : 
G[0, 1] X [0,+oo) — >• IR is defined by the following scheme: 

f ^)|tG[0,l] = G{f,t), 

1 F{f, t)\te(n,n+i] = Hf, t, XyF{f, y + n - 1)) 

Proposition 3. The functional F is generalised computable in the language with 
equality, with F defined above. 
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3 An Application to Formalisation of Hybrid Systems 

We use the models of hybrid systems proposed by Nerode, Kohn in m- A 
hybrid system is a system which consists of a continuous plant that is disturbed 
by external world and controlled by a program implemented on a sequential 
automaton. The main subject of our investigation is behaviour of the continuous 
components. We propose a logical formalisation of hybrid systems in which the 
trajectories of the continuous components (the performance specification) are 
presented by computable functionals. 

A formalisation of the hybrid system FEES = {TS,F,Convl, A,Conv2, 1) 
consists of: 

• TS = {ti}i^ui- It is an effective sequence of rational numbers i.e. the set of 

Gordel numbers of elements oiTS is computable enumerated. The rational 
numbers ti are the times of communication of the external world and the 
hybrid system, and communication of the plant and the control automaton. 
The time sequence satisfies the realizability requirements: 

1. For every i, ti > 0] to < ti < . . . < ti . . 

2. The differences ti+i — ti have positive lower bounds. 

• F : C[0, 1] X M" — >■ K. It is a generalised computable functional in the 
language trj. The plant has been given by this functional. 

• Convl : C[0, 1] x IR — >■ A* . It is an generalised computable functional in the 
following sense: Convl(f,x) = w (p{Ui,U 2 ,x,w), where Ui{xi,X 2 ,c) ^ 
f\[xi,x 2 ] > c,U 2 {xi,X 2 ,c) ^ f\[xi,x 2 ] < c and the predicate Ui and U 2 occur 
positively in A-formula ip. At the time of communication this functional con- 
verts measurements, presented by the meaning of F, and the representation 
of external world / into finite words which are input words of the internal 
control automata. 

• A : A* — >■ A*. It is a A-definable function. The internal control automata, 
in practice, is a finite state automata with finite input and finite output 
alphabets. So, it is naturally modelled by A-definable function (see | 3l6p 
which has a symbolic representation of measurements as input and produces 
a symbolic representation of the next control law as output. 

• Conv2 : A* — >■ It is a A-definable function. This function converts 

finite words representing control laws into control laws imposed on the plant. 

• / C A* U IR". It is a finite set of initial conditions. 

Definition 7. The behaviour of a hybrid system is defined by a functional 
H : C[0, 1] X IR — IR if for any external disturbation f € C[0, 1] the values of 
H{f,-) define the trajectory of the hybrid system. 

Theorem 2. Suppose a hybrid system is specified as above. If the behaviour of 
the hybrid system is defined by a continuous functional H then H is computable 
in the sense of computable analysis. 

Proof. The claim follows from Theorem 1 and Proposition 3. □ 
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In conclusion we would like to note that subjects of future papers will be 
formulation and investigation of optimal hybrid control in terms of generalised 
computability. 



References 

1. J. Barwise, Admissible sets and strnctures, Berlin, Springer- Verlag, 1975. 

2. A. Edalat, P. Siinderhanf, A domain-theoretic approach to computability on 
the real line, Theoretical Computer Science, 210, 1998, pages 73-98. 

3. Yu. L. Ershov, Definability and computability, Plenum, New York, 1996. 

4. A. Grzegorczyk, On the definitions of computable real continuous functions. Fund. 
Math., N 44, 1957, pages 61-71. 

5. T.A. Henzinger, Z. Manna, A. Pnueli, Towards refining Temporal Specifications 
into Hybrid Systems, LNCS N 736, 1993, pages 36-60. 

6. M. Korovina, O. Kudinov, A New Approach to Computability over the Reals, 
SibAM, V. 8, N 3, 1998, pages 59-73. 

7. M. Korovina, O. Kudinov, Characteristic Properties of Majorant-Computability 
over the Reals, Proc. of CSL’98, LNCS, 1584, 1999, pages 188-204. 

8. M. Korovina, O. Kudinov, A Logical approach to Specifications of Hybrid Systems, 
Proc. of PSI’99, LNCS 1755, 2000, pages 10-16. 

9. M. Korovina, O. Kudinov, Formalisation of Computability of Operators and Real- 
Valued Functionals via Domain Theory, Proceedings of CCA-2000, to appear in 
LNCS, 2001. 

10. Z. Manna, A. Pnueli, Verifying Hybrid Systems, LNCS N 736, 1993, pages 4-36. 

11. R. Montague, Recursion theory as a branch of model theory, Proc. of the third in- 
ternational congr. on Logic, Methodology and the Philos, of Sc., 1967, Amsterdam, 
1968, pages 63-86. 

12. A. Nerode, W. Kohn, Models for Hybrid Systems, Automata, Topologies, Control- 
lability, Observability, LNCS N 736, 1993, pages 317-357. 

13. W. Kohn, A. Nerode, J. B. Remmel Agent Based Velocity Control of Highway 
Systems, LNCS N 1273, 1997, pages 174-215. 

14. M. B. Pour-El, J. I. Richards, Computability in Analysis and Physics, Springer- 
Verlag, 1988. 

15. D. Scott, Outline of a mathematical theory of computation. In 4th Annual Prince- 
ton Conference on Information Sciences and Systems, 1970, pages 169-176. 

16. Viggo Stoltenberg-Hansen, John V. Tucker, Concrete models of computation for 
topological algebras, TCS 219, 1999, pages 347-378. 

17. K. Weihrauch, Computable analysis. An introduction. Springer, 2000. 




Exploring Template Template Parameters 



Roland Weiss and Volker Simonis 



Wilhelm-Schickard-Institut fiir Informatik, Universitat Tubingen 
Sand 13, 72076 Tiibingen, Germany 
{weissr, simonis}0 informatik . uni-tuebingen . de 



Abstract. The generic programming paradigm has exerted great influ- 
ence on the recent development of C-l— 1-, e.g., large parts of its standard 
library [2] are based on generic containers and algorithms. While tem- 
plates, the language feature of C-|— I- that supports generic programming, 
have become widely used and well understood in the last years, one as- 
pect of templates has been mostly ignored: template template param- 
eters ([2], 14.1). In the first part, this article will present an in depth 
introduction of the new technique. The second part introduces a class 
for arbitrary precision arithmetic, whose design is based on template 
template parameters. Finally, we end with a discussion of the benefits 
and drawbacks of this new programming technique and how it applies to 
generic languages other than C-|— 1-. 



1 Introduction 

The C-|— I- standard library incorporated the standard template library (STL) 
[15] and its ideas, which are the cornerstones of generic programming [14]. Tem- 
plates are the language feature that supports generic programming in C-I--I-. 
They come in two flavors, class templates and function templates. Class tem- 
plates are used to express classes parameterized with types, e.g., the standard 
library containers, which hold elements of the argument type. Generic algorithms 
can be expressed with function templates. They allow one to formulate an al- 
gorithm independently of concrete types, such that the algorithm is applicable 
to a range of types complying to specific requirements. For example, the stan- 
dard sort algorithm without function object ([2], 25.3) is able to rearrange a 
sequence of arbitrary type according to the order implied by the comparison 
operator <. Of course, the availability of this operator is a requirement on the 
elements’ type. 

It is possible to use instantiated class templates as arguments for class 
and function templates, therefore one is able to write nested constructs like 
vector<list<long> >. So where does the need for template template param- 
eters arise? Templates give one the power to abstract from an implementation 
detail, the types of the application’s local data. Template template parameters 
provide one with the means to introduce an additional level of abstraction. In- 
stead of using an instantiated class template as argument, the class template 
itself can be used as template argument. To clarify the meaning of this state- 
ment, we will look in the following sections at class and function templates that 
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take template template parameters. Then we will present a generic arbitrary 
precision arithmetic implemented with template template parameters. Finally, 
the presented technique is discussed and effects on other generic languages are 
considered. 



2 Class Templates 

The standard library offers three sequence containers, vector, list and deque. 
They all have characteristics that recommend them for a given application con- 
text. But if one wants to write a new class called store that uses a standard 
container internally to store values, it is hard to choose the perfect container for 
all possible scenarios. This is exactly the situation where template template pa- 
rameters fit in. The class designer can provide a default container, but the user 
can override this decision easily. Note that the user can not only use standard 
containers but also any proprietary container that conforms to the standard se- 
quence container interface. Let us look at a code example that implements the 
class store_comp using object composition, 
template < typename val_t, 

template <typename T, typename A> class cont_t = std::deque, 
typename alloc_t = std : : allocator<val_t> > 
class store_comp 
{ 

cont_t<val_t , alloc_t> m_cont; // instantiate template template parameter 

piiblic : 

typedef typename cont_t<val_t, alloc_t<val_t> >::iterator iterator; 
iterator begin () { return m_cont . begin () ; } 

// more delegated methods... 



The first template parameter val_t is the type of the objects to be kept inside 
the store. cont_t, the second one, is the template template parameter, which 
we are interested in. The declaration states that cont_t expects two template 
parameters T and A, therefore any standard conforming sequence container is ap- 
plicable. We also provide a default value for the template template parameter, 
the standard container deque. When working with template template param- 
eters, one has to get used to the fact that one provides a real class template 
as template argument, not an instantiation. The container’s allocator alloc_t 
defaults to the standard allocator. 

There is nothing unusual about the usage of cont_t, the private member 
m_cont is an instantiation of the default or user provided sequence container. 
As already mentioned, this implementation of store_comp applies composition 
to express the relationship between the new class and the internally used con- 
tainer. Another way to reach the same goal is to use inheritance, as shown in 
the following code segment: 
template <typename val_t, ...> 

class store_inh : public cont-t<val_t , alloc_t<val_t> > {}; 
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The template header is the same as in the previous example. Due to the public 
inheritance, the user can work with the container’s typical interface to change the 
store’s content. For the class store_comp, appropriate member functions must be 
written, which delegate the actual work to the private member m_cont. The two 
differing designs of class store are summarized in Figure 1. The notation follows 
the diagrams in [9]. The only extension is that template template parameters 
inside the class’ parameter list are typeset in boldface. 



i val t, alloc 
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i val t, cont t, 


containert 


< 


storejnh 



i val t, alloc 


t 


containert 


M 



store_comp 

-m_cont 
+begin(), +end() 



Fig. 1. Comparison of the competing designs of the store classes 



To conclude the overview, these code lines show how to create instances of the 
store classes: 

store_comp<std: : String, std::list> sc; 
store_inh<int> si ; 

sc uses a std: : list as internal container, whereas si uses the default container 
std: : deque. This is a very convenient way for the user to select the appropriate 
container that matches the needs in his application area. The template template 
parameter can be seen as a container policy [1]. 

Now that we have seen how to apply template template parameters to a 
parameterized class in general, let us examine some of the subtleties. 

First, the template template parameter - cont_t in our case - must be 
introduced with the keyword class, typename is not allowed ([2], 14.1). This 
makes sense, since a template template argument must correspond to a class 
template, not just a simple type name. 

Also, the identifiers T and A introduced in the parameter list of the template 
template parameter are only valid inside its own declaration. Effectively, this 
means that they are not available inside the scope of the class store. One can 
instantiate the template template parameter inside the class body with differ- 
ent arguments multiple times, which would render the identifier(s) ambiguous. 
Hence, this scoping rule is reasonable. 

But the most important point is the number of parameters of the template 
template parameter itself. Some of you may have wondered why two type pa- 
rameters are given for a standard container, because they are almost exclusively 
instantiated with just the element type as argument, e.g., std: : deque<float>. 
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In these cases, the allocator parameter defaults to the standard allocator. Why 
do we have to declare it for cont_t? The answer is obvious: the template pa- 
rameter signatures of the following two class templates Cl and C2 are distinct, 
though some of their instantiations can look the same: 

template <typename T> class Cl { } ; 

template <typename Tl, typename T2 = int> class C2 {}; 

Cl<double> cl; // cl has signature Cl<double> 

C2<double> c2; // c2 has signature C2<double, int> 

In order to be able to use standard containers, we have to declare cont_t con- 
forming to the standard library. There ([2], 23.2), all sequence containers have 
two template parameters.^ This can have some unexpected consequences. Think 
of a library implementor who decides to add another default parameter to a 
sequence container. Normal usage of this container is not affected by this imple- 
mentation detail, but the class store can not be instantiated with this container 
because of the differing number of template parameters. We have encountered 
this particular problem with the deque implementation of the SGI STL [23].^ 
Please note that some of the compilers that currently support template template 
parameters fail to check the number of arguments given to a template template 
parameter instantiation. 

The template parameters of a template template parameter can have default 
arguments themselves. For example, if one is not interested in parameterizing 
a container by its allocator, one can provide the standard allocator as default 
argument and instantiate the container with just the contained type. 

Finally, we will compare the approach with template template parameters 
to the traditional one using class arguments with template parameters. Such a 
class would look more or less like this: 
template <typename cont_t> 
class store_t 

cont_t m_cont ; // use instantiated container for internal representation 

piiblic : 

typedef typename cont_t :: iterator iterator; // iterator type 

typedef typename cont_t : : value_type value_type; // value type 

typedef typename cont_t : : allocator_type allocator_type; // alloc type 

// rest analogous to store-Comp ... 

}; 

typedef std: : list<int> my_cont; // container for internal representation 
store_t<my_cont> st; // instantiate store 

We will examine the advantages and drawbacks of each approach. The traditional 
one provides an instantiated class template as template argument. Therefore, 
store_t can extract all necessary types like the allocator, iterator etc. This is 
not possible in classes with template template parameters, because they perform 
the instantiation of the internal container themselves. 



^ The C-I--I- Standardization Committee currently discusses if this a defect, inade- 
quately restricting library writers. 

^ The additional third template parameter was removed recently. 
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But the traditional approach was made applicable at all by the fact that the 
user provides the type with which the sequence container is instantiated. If the 
type is an implementation detail not made explicit to the user, the traditional 
approach doesn’t work. See [21] for an application example with these properties. 
The ability to create multiple, different instantiations inside the class template 
body using the template template argument is also beyond the traditional ap- 
proach: 

cont_t<int, alloc_t> cont_l; 

cont_t<val_t, std: :allocator<val_t> > cont_2; 



3 Function Templates 

In the preceding section we showed that by application of template template 
parameters we gain flexibility in building data structures on top of existing STL 
container class templates. Now we want to examine what kind of abstractions are 
possible for generic functions with template template parameters. Of course, one 
can still use template template parameters to specify a class template for internal 
usage. This is analogous to the class store_comp, where object composition is 
employed. 

But let us try to apply a corresponding abstraction to generic functions as 
we did to generic containers. We were able to give class users a convenient way 
to customize a complex data structure according to their application contexts. 
Transferring this abstraction to generic functions, we want to provide functions 
whose behavior is modifiable by their template template arguments. 

We will exemplify this by adding a new method view to the class store. 
Its purpose is to print the store’s content in a customizable way. A bare bones 
implementation inside a class definition is presented here: 

template <template <typename iter_t> class mutator> 
void view ( std :: ostream& os) 

{ 

mutator<iterator> ( ) (begin (), end ()) ; // iterator: defined in the store 
std :: copy (begin 0 , end () , std : : ostream_iterator<val_t> (os , " ") ) ; 

} 

Here, mutator is the template template parameter, it has an iterator type as 
template parameter. The mutator changes the order of the elements that are 
delimited by the two iterator arguments and then prints the changed sequence. 
This behavior is expressed in the two code lines inside the method body. The first 
line instantiates the mutator with the store’s iterator and invokes the mutator’s 
application operator, where the elements are rearranged. In the second line, the 
mutated store is written to the given output stream os, using the algorithm 
copy from the standard library. The types iterator and val_t are defined in 
the store class. 

The first noteworthy point is that we have to get around an inherent problem 
of C-|— k: functions are not first order objects. Fortunately, the same workaround 
already applied to this problem in the STL works fine. The solution is to use 
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function objects (see [15], chapter 8). In the view method above, a function 
object that takes two iterators as arguments is required. 

The following example shows how to write a function object that encapsulates 
the random_shuf f le standard algorithm and how to call view with this function 
object as the mutator: 

// function object that encapsulates std: : random^shuffle 

template <typename iter_t> 
struct RandomShuf f le 
1 

void operator 0 (iter_t il, iter_t 12) { std : : random_shuf f le ( il , 12); } 

}; 

// A store s must be created and filled with values... 
s . view<RandomShuf f le> (cout ) ; // RandomShuf fie is the mutator 

There are two requirements on the template arguments such that the presented 
technique works properly. First, the application operator provided by the func- 
tion object, e.g., RandomShuf fie, must match the usage inside the instantiated 
class template, e.g., store_comp. The view method works fine with applica- 
tion operators that expect two iterators as input arguments, like the wrapped 
random_shuf f le algorithm from the standard library. 

The second requirement touches the generic concepts on which the STL is 
built. RandomShuf fie wraps the random_shuf f le algorithm, which is specified 
to work with random access iterators. But what happens if one instantiates the 
store class template with std: : list as template template argument and calls 
view<RandomShuf f le>? std: : list supports only bidirectional iterators, there- 
fore the C-|— I- compiler must fail instantiating view<RandomShuf f le>. If one is 
interested in a function object that is usable with all possible store instantia- 
tions, two possibilities exist. Either we write a general algorithm and demand 
only the weakest iterator category, possibly loosing efficiency. Or we apply a 
technique already used in the standard library. The function object can have 
different specializations, which dispatch to the most efficient algorithm based 
on the iterator category. See [4] for a good discussion of this approach. This 
point, involving iterator and container categories as well as algorithm require- 
ments, emphasizes the position of Musser et. al. [16] that generic programming 
is requirement oriented programming. 

Completing, we want to explain why template template parameters are nec- 
essary for the view function and simple template parameters won’t suffice. The 
key point is that the mutator can only be instantiated with the correct iterator. 
But the iterator is only know to the store, therefore an instantiation outside 
the class template store is not possible, at least not in a consistent manner. 

Overall, the presented technique gives a class or library designer a versatile 
tool to make functions customizable by the user. 

4 Long Integer Arithmetic — An Application Example 

Now we will show how the techniques introduced in the last two sections can 
be applied to a real world problem. Suppose you want to implement a library 
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for arbitrary precision arithmetic. One of the main problems one encounters 
is the question of how to represent long numbers. There are many well known 
possibilities to choose from: arrays, single linked lists, double linked lists, garbage 
collected or dynamically allocated and freed storage and so on. It is hard to make 
the right decision at the beginning of the project, especially because our decision 
will influence the way we have to implement the algorithms working on long 
numbers. Furthermore, we might not even know in advance all the algorithms 
that we eventually want to implement in the future. 

The better way to go is to leave this decision open and parameterize the long 
number class by the container, which holds the digits. We just specify a minimal 
interface where every long number is a sequence of digits, and the digits of every 
sequence have to be accessible through iterators. With this in mind, we can 
define our long number class as follows: 
template< 

template<typename T, typename A> class cont_t = std: :vector, 
template<typename AllocT> class alloc_t = std: : allocator 

> 

class Integer { 

// . . 

}; 

The first template template parameter stands for an arbitrary container type, 
which fulfills the requirements of a STL container. As we do not want to leave the 
memory management completely in the container’s responsibility, we use a sec- 
ond template template parameter, which has the same interface as the standard 
allocator. Both template template parameters have default parameters, namely 
the standard vector class std: : vector for the container and the standard allo- 
cator std:: allocator for the allocator. 

Knowing only this interface, a user could create integer instances, which 
use different containers and allocators to manage a long number’s digits. He even 
does not have to know if we use composition or inheritance in our implementation 
(see Figure 1 for a summary of the two design paradigms).^ 

In order to give the user access to the long number’s digits, we implement the 
methods begin ( ) , end ( ) and push_back ( ) , which are merely wrappers to the 
very same methods of the parameterized container. The first two return iterators 
that give access to the actual digits while the last one can be used to append a 
digit at the end of the long number. Notice that the type of a digit is treated as 
an implementation detail. We only have to make it available by defining a public 
type called digit-type in our class. Also we hand over in this way the type 
definitions of the iterators of the underlying containers. Now, our augmented 
class looks as follows (with the template definition omitted): 

® We used composition in our implementation. The main reason was that we wanted to 
minimize the tradeoff between long numbers consisting of just one digit and real long 
numbers. Therefore, our Integer class is in fact a kind of union or variant record 
in Pascal notation of either a pointer to the parameterized container or a plain digit. 
The source code of our implementation is available at http://www-ca.informatik.uni- 
tuebingen.de/people/simonis/projects.htm. 
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class Integer { 
public : 

typedef int digit-type; 

typedef typename cont_t :: iterator iterator; 
iterator begin () { return cont->begin ( ) ; } 

iterator end() { return cont->end(); } 
void push-back (digit-type v) { cont->push-back (v) ; } 

private : 

cont-t<digit-type, alloc-t> *cont ; 

}; 

With this in mind and provided addition is defined for the digit type, a user 
may implement a naive addition without carry for long numbers of equal length 
in the following way (again the template definition has been omitted): 

Integer<cont-t, alloc-t> 

add (Integer<cont_t, alloc_t> &a, Integer<cont_t , alloc_t> &b) { 

Integer<cont_t, alloc_t> result; 

typename Integer<cont-t , alloc-t> : : iterator ia=a . begin ( ) , ib=b . begin ( ) ; 
while(ia != a.endO) result . push-back ( *ia + *ib) ; ) 
return result; 



Based on the technique of iterator traits described in [5] and the proposed con- 
tainer traits in [4] specialized versions of certain algorithms may be written, 
which make use of the specific features of the underlying container. For ex- 
ample, an algorithm working on vectors can take advantage of random access 
iterators, while at the same time being aware of the fact that insert operations 
are linear in the length of the container. 

5 Conclusions and Perspectives 

We have shown how template template parameters are typically employed. They 
can be used to give library and class designers new power in providing the user 
with a facility to adapt the predefined behavior of classes and functions according 
to his needs and application context. This is especially important if one wants 
to build on top of already existing generic libraries like the STL. 

With our example we demonstrate how template template parameters and 
generic programming can be used to achieve a flexible design. In contrast to usual 
template parameters, which parameterize with concrete types, template template 
parameters allows one to parameterize with incomplete types. This is a kind of 
structural abstraction compared to the abstraction over simple types achieved 
with usual template parameters. As templates are always instantiated at compile 
time, this technique comes with absolutely no runtime overhead compared to 
versions which don’t offer this type of parameterization. 

One has to think about the applicability of template template parameters, 
a C-|— I- feature, to other programming languages. Generally, a similar feature 
makes sense in every language that follows C-|— l-’s instantiation model of re- 
solving all type bindings at compile time (e.g., Modula-3 and Ada). Template 
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template parameters are a powerful feature to remove some restrictions imposed 
by such a strict instantiation model without introducing runtime overhead. 

We measured our example with GCC 2.97 and two versions of the STL, 
namely the from SGI [23] and one from Rogue Wave [20] . Table 1 compares our 
Integer class with some widely available arbitrary precision libraries (GMP 
3.1.1 [11], GLN 1.0.3 [12], NTL 4.1a [22] and Piologie 1.2.1 [24]). The tests have 
been done on a Pentiumlll 667MHz Linux system using the PGL library [6]. 

The results of some tests with garbage collected containers using the Boehm- 
Weiser-Demers [7] collector have been not very promising. However the signif- 
icant performance difference between the two STL versions we used indicate 
that this may be no fundamental problem, but a problem of bad compiler op- 
timization and the orthogonal design of the SGI-STL containers and the plain 
Boehm- Weiser-Demers garbage collector. Therefor we plan further tests in the 
future using optimizing compiler and other collectors like TGG [18], [19], which 
address exactly this problems. 

6 Compiler Support 

One major problem in working with template template parameters is not a con- 
ceptual, but rather a practical one. Even now, three years after the publication 
of the ISO G-I--I- standard, not all compilers implement this feature. 

We were able to compile our examples only with the following compilers: 
Borland G-l— I- V5.5 [3], Visual Age G-l— I- V4.0 [13], Metrowerks V6.0 and all 
compilers based on the edg front-end V2.43 [8]. The snapshot versions after 
November 2000 of the Gnu G-l— I- Gompiler [10] also meet the requirements. 

Acknowledgements. We want to thank Rudiger Loos for his ideas on nested 
lists and long integers based on STL containers, which sparked our interest in 
template template parameters. We also want to thank the guys from EDG [8] 
for always supplying us with the newest version of their fabulous compiler and 
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Abstract. Dynamic memory management is a known performance 
bottleneck of Java applications. The problem arises out of the Java 
memory model in which all objects (non-primitive type instances) are 
allocated on the heap and reclaimed by garbage collector when they are 
no longer needed. This paper presents a simple and fast algorithm for 
inference of object lifetimes. Given the analysis results, a Java compiler 
is able to generate faster code, reducing the performance overhead. 
Besides, the obtained information may be then used by garbage collector 
to perform more effective resource clean-up. Thus, we consider this 
technique as “compile-time garbage collection” in Java. 

Keywords: Java, escape analysis, garbage collection, finalization, per- 
formance 



1 Introduction 

Java and other object-oriented programming languages with garbage collection 
are widely recognized as a mainstream in the modern programming world. They 
allow programmers to embody problem domain concepts in a natural coding 
manner without paying attention to low-level implementaion details. The other 
side of the coin is often a poor performance of applications written in the lan- 
guages. The problem has challenged compiler and run-time environment de- 
signers to propose more effective architectural decisions to reach an acceptable 
performance level. 

A known disadvantage of Java applications is exhaustive dynamic memory 
consumption. For the lack of stack objects — class instances put on the stack 
frame, all objects have to be allocated on the heap by the new operator. Pres- 
ence of object-oriented class libraries makes the situation much worse because 
any service provided by some class, prerequires the respective object allocation. 
Another problem inherent to Java is a so-called pending object reclamation PQ 
that does not allow garbage collector to immediately utilize some objects even 
though they were detected as unreachable and finalized. The Java Language 
Specification imposes the restriction on an implementation due to the latent 
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caveat: if an object has a non-trivial finalizer (the Object. finalize() method 
overriden) to perform some post-mortem clean-up, the finalizer can resurrect its 
object ’’from the dead”, just storing it, for instance, to a static field. Pending 
object reclamation reduces memory resources available to a running application. 

Generally, performance issues can be addressed in either compiler or run-time 
environment. Most Java implementations (e.g. [a m tend to improve memory 
management by implementing more sophisticated algorithms for garbage collec- 
tion [3]. We strongly believe that the mentioned problems should be covered in 
both compile-time analysis and garbage collection to use all possible opportuni- 
ties for performance enhancement. 

Proposition 1. Not to junk too much is better than to permanently collect 
garbage 

We propose a scalable algorithm for object lifetime analysis that can be 
used in production compilers. We implemented the system in JET, Java to 
native code compiler and run-time environment based on the Excelsior’s compiler 
construction framework |5]. 

The rest of the paper is organized as follows: Section ^describes the program 
analysis and transformation for allocating objects on the stack rather than on the 
heap. Section |3] describes our improvements of the Java finalization mechanism. 
The obtained results are presented in Section [Jj Section |5] highlights related 
works and, finally. Section El summarizes the paper. 

2 Stack Allocating Objects 

In Java programs, the lifetimes of some objects are often obvious whereas the 
lifetimes of others are more uncertain. Consider a simple method, getting the 
current date: 

int fooO { 

Date d = new DateO; 
return d.getDateO; 

} 



At the first glance, the lifetime of the object d is resctricted to that of method 
/go’s stack frame. That is an opportunity for a compiler to remove the new 
operator and allocate the object on the stack. However, we have to guarantee 
that no d aliases escape from the stack frame, that is, no aliased references to 
d are stored anywhere else. Otherwise, such program transformation would not 
preserve the original Java semantics. In the above example, the method getDate 
is a possible ’’escape direction”. 

Escape analysis dating back to the middle 1970s [6], addresses the problem. 
Many algorithms proposed vary in their application domains and time and spa- 
tial complexity. We designed a simple and fast version of escape analysis specially 
adapted to Java. Despite its simplicity, the algorithm shows promising results of 
benchmarking against widespread Java applications. 
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2.1 Definitions 

All variables and formal parameters in the below definitions are supposed to 
be of Java reference types. By definition, formal parameters of a method also 
include the implicit ’’this” parameter (method receiver). 

Definition 1 (Alias). An expression expr is an alias of a variable v at a par- 
ticular execution point, if v == expr (both v and expr refer to the same Java 
object) 

Definition 2 (Safe method). A method is safe w.r.t its formal parameter, if 
any call to the method does not create new aliases for the parameter except, may 
be, a return value 

Definition 3 (Safe variable). A local frame variable is safe, if no its aliases 
are available after method exit 

Definition 4 (Stackable type). A reference type is stackable, if it has only a 
trivial finalizer 

Definition 5 (A-stackable variable). A safe variable v is A-stackable, if a 
definition of v has the form of v = new T(..) for some stackable type 

Definition 6 (Stackable variable). An A-stackable variable is stackable, if 
no local aliases of the variable exist before a repetitive execution of the variable 
definition in a loop, if any 

The stackable type definition is used to hinder a possible reference escape 
during finalizer invocation. The A-stackable to stackable variable refinement is 
introduced to preserve the semantics of the new operator: being executed in a 
loop, it creates different class instances so the analysis has to guarantee that 
previously cretead instances are unavailable. 



2.2 Program Analysis and Transformation 

To detect if a variable is not safe, we distinguish two cases of escape: 

1. explicit return v, throw v or w. field = v (an assignment to a static or 
instance field) 

2. implicit: foo (...,v, ..) invocation of a method non-safe w.r.t v 

Operators like v = vl are subject for a flow-insensitive analysis of local reference 
aliases (LRA) [T0|. In order to meet the requirement for loop-carried variable 
definitions, the algorithm performs a separate LRA-analysis within loop body. 
Determining of safe methods is proceeded recursively as a detection of their 
formal parameter safety except the return operator. In such case, the return 
argument becomes involved into local reference aliasing of the calling method. 
We implemented our algorithm as a backward inter-procedural static analysis on 
call graph like algorithms described in related works 0 , 11 ]. We omit the common 
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analysis scheme due to its similarity to those of related works and focus on some 
important differencies further. 

Once stackable variables have been detected, the respective v = new T(..) 
operators are replaced with the v = stacknew T(..) ones from internal program 
representation. Besides, the operators like v = new Tfexprj, allocating variable 
length arrays are marked with a tag provided for subseqent code generation. 
That makes sense because our compiler is able to produce code for run-time 
stack allocation. 

2.3 Implementation Notes 

The Excelsior’s compiler construction framework features a statistics back-end 
component [S] making it a suitable tool of statistic gathering and processing for 
any supported input language. Also, we had a memory allocation profiler in the 
run-time component so we were able to analyze a number of Java applications. 
We found that the algorithms described in related works may be somewhat 
simplified without sacrificing effectiveness. Moreover, the simplification often 
leads to better charateristics such as compilation time and resulting code size. 

Type inference. So far, we have (implicitly) supposed that all called meth- 
ods are available for analysis. However, Java being an object-oriented language, 
supports virtual method invocation — run-time method dispatching via Virtual 
Method Tables that hinders any static analysis. Type inference [T^ is often used 
to avoid the problem to some extent. Our algorithm employs a context-sensitive 
local type inference: it starts from the known local types sourcing from local new 
T(..) operators and propagates the type information to called method context. 
We used a modified version of the rapid type inference pursued in m- Another 
opportunity which helps to bypass the virtual method problem is global type 
inference based on the class hierarchy analysis m- We implemented a similar 
algorithm but its applicability is often restricted because of the Java dynamic 
class loading. We did not consider polyvariant type inference (analysis of differ- 
ent branches at polymorphic call sites) due to its little profit in exchange for the 
exponential complexity. 

Inline substitution. Local analysis in optimizing compilers is traditionally 
stronger than inter-procedural because, as a rule, it requires less resources. This 
is why inline substitution not only removes call overhead but also often im- 
proves code optimization. Escape analysis is not an exception from the rule: 
local variables that were not stackable in the called method may become so in 
the calling one, for instance, if references to them escaped via the return opera- 
tor. Escape analysis in Marmot j7] specially treats called methods having that 
property to allocate stack variables on the frame of calling method. In the case, 
called method should be duplicated and specialized to add an extra reference 
parameter (Java supports metaprogramming so the original method signature 
may not be changed). In our opinion, that complicates analysis with no profit: 
the same problem may be solved by an ordinary inline substitution without the 
unnecessary code growth. 
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Native method models. The Java language supports external functions called 
native methods. They are usually written in C and unavailable for static analy- 
sis. However, certain native methods are provided in standard Java classes and 
should be implemented in any Java run-time or even compiler, for instance the 
System. arraycopy method. Because the behaviour of such methods is strictly 
defined by the Java Language Specification [T], we benefit from using so-called 
model methods provided for analysis purposes only. A model native method has 
a fake implementation simulating the original behaviour interesting for analysis. 
Employing model methods improves the overall precision of escape analysis. 

2.4 Complexity 

In according to in. given restrictions even weaker than ours, escape analysis can 
be solved in linear time. The rejection of analyzing polyvariant cases at virtual 
call sites and the restriction of reference aliasing to local scopes only give the 
complexity proportional to N (program size) -I- G (non- virtual call graph size). 
Thus, our algorithm performs in 0(N-|-G) both time and space. 

3 Finalization 

The described algorithm determining safe methods may be used for more effective 
implementation of pending object reclamation in Java. As mentioned above, an 
object having a non-trivial finalizer is prevented from immediate discarding by a 
garbage collector. The main problem provoking a significant memory overhead is 
that all heap subgraph reachable from the object may not be reclaimed as well: 
finalizer may potentially ’’save” (via aliasing) any object from the subgraph. 

To overcome the drawback, we adapted the algorithm to detect whether 
the finalizer is a safe method with respect to its implicit ’’this” parameter and 
other object’s fields aliased from ’’this”. The analysis results are then stored by 
compiler to the class object (a Java metatype instance m)- Given that, garbage 
collector makes a special treatment for objects with trivial or safe finalizers. More 
specifically, the run-time system constructs a separate list for objects which 
require pending reclamation whereas other objects are processed in a simpler 
way. The measurement results for the optimization are listed in the next section. 



4 Results 

We implemented the described optimizations as a part of the JET compiler 
and run-time environment. We selected the Javacc parser generator, the Javac 
bytecode compiler from Sun SDK 1.3 and Gaffein Dhrystone/ Strings bench- 
marks to evaluate resulting performance of the escape analysis application. The 
results are shown in Table 1 (the numbers were computed as NewExecution- 
Time/OldExecutionTime). The performance growth is achieved as a result of 
both faster object allocation and less extensive garbage collection. 

These tests were choosen due to their batch nature that allows us to mea- 
sure the difference in total execution time. Despite the results for the first three 
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benchmarks are valuable, applying the optimization to the Javac compiler had 
only minimal effect — no silver bullet. Unfortunately, the results may not be di- 
rectly compared with the results obtained by other researchers. The comparison 
of different algorithms may be accomplished only within the same optimization 
and run-time framework. For instance, a system with slower object allocation 
and garbage collection or better code optimization would obviously experience 
more significant performance improvement from the stack allocation. 

Results of optimized finalization are given in Table 2. JFC samples (Rota- 
torSD, Clipping, Transform, Lines) using Java 2D-graphics packages were cho- 
sen because of very intensive memory consumption. We measured the amount 
of free memory just after garbage collecting and the numbers were computed as 
NewPreeMemory/ OldFreeMemory. The total amount of heap memory was the 
same for all tests and equal to 30MB. 



Table 1. Stack allocating objects 



Benchmark 


Execution time fraction 


Javacc 


0.54 


Dhrystone 


0.32 


Strings 


0.2 


Javac 


0.98 



Table 2. Optimized finalization 



Benchmark 


Free memory fraction 


Memory profit, MB 


RotatorSD 


1.1 


-fl.5 


Clipping 


1.15 


+ 1.2 


Transform 


1.08 


+0.7 


Lines 


1.13 


+1.7 



We noted that even with the optimizations enabled, the total compilation 
time remains virtually unchanged. Analyzing obtained results, we draw a con- 
clusion that the considered object-oriented optimizations may be employed by 
production compilers. All further information related to the JET project may 

be found at m- 

5 Related Works 

An number of approaches have been proposed for object lifetime analysis. Many 
works were dedicated to functional languages such as SML, Lisp etc. (H3], [IH], 
m)- The power of the escape analyses supercedes ours to a great extent, however 
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the complexity of the algorithms is not better than polynomial. The escape anal- 
ysis for Java was investigated by reseachers using static Java analyzing frame- 
works. Except the JET compiler, the related works were completed on the base 
of the TurboJ via-C translator |E], the IBM HPJ compiler m and the Marmot 
compiler project at Microsoft Research |7]. The algorithm presented is simpler 
but, nevertheless, quite effective and precise so it may be used even in dynamic 
compilers built in the most current Java Virtual Machines 0) 0- Besides, the 
related works discuss only stack allocating objects whereas our approach also 
considers garbage collection improvement basing on the compile-time analysis. 

6 Conclusion 

This paper presented a technique for fast and scalable object lifetime analysis. 
Being used in cooperative compiler and run-time framework, the implemented 
optimizations profit in both execution speed and memory consumption of Java 
applications. The interesting area for future works is to investigate a region 
inference algorithms allowing compiler to approximate object lifetimes between 
method call boundaries. Despite the applicability of such analysis to compiler 
optimizations is doubt, the information may be used for more effective garbage 
collection in compiler-cooperative run-time environment. 
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Abstract. The actually achieved benefits of using binary software com- 
ponents are not as revolutionary as promised. Component platforms are 
available but the composition process is not “componentized” . We pro- 
pose to increase the automation of software composition along with the 
necessary degree of flexibilty by introducing a set of languages (CoPL 
and CoML) and tools. By automating the composition process routine 
tasks are performed by tools. Additionally, software engineers can pre- 
serve and instantiate composition patterns in CoPL and CoML and thus 
at a higher level of abstraction than at the level of pure glue code. 



1 Introduction 

Binary software components offer solutions to various software engineering prob- 
lems, e.g. how to build and maintain complex software systems in a changing 
environment. The idea is to acquire prefabricated, well-tested and platform in- 
dependent binary software components on the market and to compose them to 
new applications by plugging them together in builder tools without the need for 
coding. There are already markets [T] for components as well as some common 
understanding about the term software component [^: 

A component is a unit of composition with contractually specified 
interfaces and explicit context dependencies only. A software component 
can be deployed independently and is subject to composition by third 
parties. 

The composition of binary software components divides the development process 
into two parts. First, component developers write new component libraries and 
they distribute or deploy the components over a market. Second, third parties 
like e.g. application programmers use them to compose their applications. Often 
different individuals assume these roles. This leads to a knowledge gap, as the 
application programmer has to determine how and in which context he can 
apply the different components. Of course, a component provider has to state 
what the components need in order to work. The component provider defines 
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the component’s context dependencies in a (hopefully) proper documentation 
and often he additionally provides example code, too. 

With Component Plan Language (CoPL) and Component Markup Language 
(CoML) we try to provide tools for the last part of the above component defini- 
tion: tools for component composition by third parties. 

Despite the used component definition we had to investigate the technical 
requirements of a component — being more precise: which requirements compo- 
nents need to be composable with CoPL and CoML: 

— A binary component is accessed via public interfaces. 

— A component provides one or more strongly typed interfaces. 

— A single interface offers methods and / or properties. Properties can be read 
and set. 

— The primary composition model is connection oriented and this model is 
implemented by an event mechanism. 

— The component life-cycle is split into design-time and run-time and thus 
between wiring components versus creating instances. 

The requirements are oriented on industry component technology standards like 
Microsofts COM and .NET [^, Suns JavaBeans [4j and Enterpirse JavaBeans 
[5], and OMGs CORBA |6]. 

Before we present CoPL and CoML, we look at the motivation behind our 
approach. Why we did not use existing approaches is explained in section 5. 
Finally, in section 6 we draw some conclusions and outline the plans for the 
future. 

2 Motivation and Usage Scenario for CoPL and CoML 

In this section we present the motivation or the basic ideas behind our approach. 
We introduce the ideas of component plans and Decision Spots for improving 
the automation of the component composition process. 

A component plan describes how an application programmer typically glues 
components of a given library together. A plan is a description of a composition 
with optional Decision Spots. Typically a plan is written in the Component Plan 
Language (CoPL) and captures domain knowledge and typical usage scenarios or 
composition patterns by providing a typical pre-wiring of the used components. 
The application programmer processes the CoPL plans with a CoML generator. 
The generator produces a detailed component composition description in Com- 
ponent Markup Language (CoML) code. CoML is an XML [5] application which 
is component platform and tool independent. Figure 1 shows a typical usage 
scenario for CoPL and CoML. 

The generator uses the plan as input and — if stated in the plan — asks 
the application programmer to substitute the declared place-holders by concrete 
components from a list of matching component implementations. We call these 
place-holders Decision Spots. Currently the matching algorithm is based on type 
substitutability or on syntax and not on semantic information. 
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Fig. 1. CoPL and CoML Usage Scenario 



On the one hand writing glue code manually gives the application assembler 
great flexibility, where on the other hand tools (e.g. wizards) automate routine 
and clearly predeflned composition tasks, like generating a code snippet for a 
new GUI dialog. A possible way for combining the advantages of these composi- 
tion techniques is to introduce a ’’script-able generator”. In fact, a CoPL plan is 
used for scripting the CoML generator. The interpreted plan guides application 
programmers semi-automatically (similarly to a wizard) through the assembly 
process for example by displaying a dialog for choosing the desired implementa- 
tion (e.g. ArrayListlmpl) for a given interface (e.g. for an ’’IList” interface). In 
contrast to a wizard, a plan is not fixed but can be modified. It is like a com- 
position template with some degrees of freedom. A plan may contain Decision 
Spots that offer choices to the application programmer. 

Considering a library with many components, it is a tedious task to And 
the right components and to instantiate and glue them together according to 
the desired composition pattern. Our component plans along with the generator 
automate this process by supplying the programmer with knowledge about how 
the component developer intended to wire the components. 

CoPL is based on previous work on JavaBeans composition using plans (see 
|S]). However, CoPL and CoML are not tuned toward a special component tech- 
nology like JavaBeans, or Microsoft’s .NET components. 

3 CoPL — Component Plan Language 

Component plans describe component compositions at an abstract level. A plan 
describes which components are used, how they are configured and how they are 
composed. A plan can contain Decision Spots. CoPL code is used for controlling 
the output of the CoML generator. CoPL is executed at design time and not 
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at run time like other composition and scripting languages (e.g. like JavaScript 
|l3j, Piccola 

The predecessor of CoPL was the JavaBeans oriented bean plan. The syntax 
of a bean plan is oriented on the Syntax of C++, C# or Java because we consider 
the syntax of widely used general purpose programming languages more readable 
than XML. However, currently we are migrating the bean plan language to the 
platform independent Component Plan Language and we are considering to use 
XML as CoPLs meta schema. 

Example 1. The following simple example uses the C like syntax. In this plan 
we are combining a collection component with a printer component. MyCollec- 
tions.IList represents a list interface. Whenever a component is added to the list, 
the Change event is fired. The component “out” handles this event. 

plan ListWithPr interExample { 

//simple decision spot 

spot Listlmpl = <MyCollections . IList > ; 
comp out = new Test . Printer {} 
comp list = new Listlmpl { 

Size = 5; //set the property 

on Change call out . PrintLn (" event □ f iredu : ~ ; 

} 

} 

CoPL allows the description of components, properties, methods, events, aggre- 
gation and of Decision Spots. Table[T|gives an overview of the offered abstractions 
in CoPL. 

The Decision Spots give the plans the needed flexibility and are explained in 
more detail. Example H] shows the use of a simple Decision Spot (Listlmpl). The 
spot declares the used interface IList and not the exact implementation. It offers 
the application programmer the choice to select one concrete MyCollections. IList 
implementation. The creator of a plan uses interactive Decision Spots whenever 
he does not know the exact type or implementation of a component. He delegates 
the final decision to the application programmer who runs the CoML generator. 
The result of a Decision Spot is either the name of a concrete component imple- 
mentation or null. If the result of the spot is used to create a new component 
instance (like a new list) and the spots value is null, the instance is not used. 

A Decision Spot rule declares one or several choices. A choice declares an 
interface and the CoML generator has to find those components that implement 
the given interfaces. Interfaces are organized in an object oriented manner: They 
are part of an inheritance hierarchy. Thus, the rule of a decision spot can narrow 
the search vertical and horizontal (see Figure [ 21 ). A vertically search is limited 
to a particular inheritance branch. An example is the search for all implementa- 
tions of the IList interface (B) which also includes the implementations for the 
IDictionary interface (C). A horizontally search can cover all implementations 
of a given set of interfaces. They don’t need to belong to the same base type. An 
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Table 1. CoPL overview 



Abstraction 

Plan 



Component 

Event 

Containment 
Decision Spot 



Method and 
property 
Customizer and 
property editor 



Description 

The plan itself. A plan contains several declared compo- 
nents and Decision Spots. The components are connected 
via events or via aggregation. 

The description of the used component implementation 
and interface. 

Associates event source (component one), event and 
event handler (compo-nent two) with each other. 
Aggregation based composition description for adding 
components to a container. 

A spot consists of a rule for finding a concrete component 
implementation, or for selecting the value for a certain 
property of a component. 

For setting and getting the properties of a used compo- 
nent and calling arbitrary methods. 

Some component models (JavaBeans, COMs ActiveX 
controls and successors) introduce special editors for cus- 
tomizing a component interactively during design time. 



Example is the search for implementations of ICollection (A) and for ButtonCtrl 
types (D). 




Fig. 2. Horizontal and vertical search within the type hierarchy 



Decision Spots can depend on each other. The result of a Decision Spot 
can influence the set of choices of another Decision Spot. We defined a simple 
dependency check (like an if statement) where the set of choices of a spot s2 can 
vary depending on the selection of a previous executed spot si. 

Example 2. This example shows the horizontal and vertical selection mechanism. 
The search rule covers three types and is encoded within angle brackets (< >). 
The horizontal search alternatives are separated by a — . 
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spot layout = <FlowLayout I BorderLay out I 
fixed CardLayout>; 

The Decision Spot in example |2] gives the application programmer the choice 
between three possible components given by the types FlowLayout, BorderLay- 
out, and CardLayout. When the CoML generator encounters this spot, it opens 
a dialog containing all implementations of the three types with all available sub- 
type implementations of the first two alternatives. The application programmer 
can select on of the implementations. If the implementation of possible subtypes 
should be omitted like for CardLayout, one has to insert the keyword fixed. 
Only those implementations are offered as a choice which directly implement 
CardLayout. 

Decision spots allow the dynamic extensibility of plans. Subtypes and their 
implementations, like e.g. MyBorderLayout, known only to the application pro- 
grammer are displayed in the selection dialog, even though the creator of the 
plan does not know them. 

4 CoML — Component Markup Language 

The Component Markup Language (CoML) is an XML application for com- 
posing software components. The main goal for CoML is to have a platform 
independent description of a component composition which is process-able by 
various software tools like development tools. CoML can be interpreted like other 
scripting languages. In our intention CoML should primarily be created and used 
by software tools rather than require humans to manually write (and execute) 
CoML scripts. However, in the spirit of XML, we still tried to make CoML hu- 
man readable as well and developed an interpreter for the Java and the .NET 
platform. 

In section 1 we introduced the term component. We stated requirements for 
components and for composition languages. Based on this requirements, CoML 
offers abstractions (i.e. XML tags, see also Tabled for describing a component 
composition. CoML tags can be used for: 

— describing which component library and version are used and additional 
component platform dependent information (see meta and info elements); 

— describing a component itself by stating the desired interface and implemen- 
tation (see components and component elements); 

— describing the customization of a component (see property and 
method-call elements); 

— describing the component composition (see on-event and add elements). 



Example 3. This CoML snippet shows the composition of two components: a 
list component and a printer component (see also the CoPL example [TJ. The 
list component fires a change event, whenever an item is added to the list. The 
printer component reacts on the change event and prints “event fired :-)” on the 
console. 
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Table 2. CoML elements (tags) 



Element name 


Description 


coml 


root element 


meta 


contains the meta information 


components 


list of composed components; contains jcomponent ...i 
elements 


component 


declares a component 


property 


sets or gets a property of a specific component 


method-call 


calls a method 


on-event 


describes an event binding; connection based composition 


add 


adds another component; aggregation based composition 


string, int, ... 


elements for primitive data types 



Additionally, each element has several attributes. 



<?xml ver sion = " 1 . 0 " encoding= " utf -8 " ?> 

<coml name=" ListWithPrinterExample " ver s ion = " 0 : 0 : 0 : 1 " > 

<meta> 

<info type="java" ver s ion = " 1 . 3 " > 

<!-- additional (linker) info: --> 

<!-- used libraries + versions --> 

</ inf o > 

</ meta> 

< component s > 

<component id = "out" clas s = " Test . Print er " /> 

<component id = "list" inter f ace = " MyCollect ions . ILi st " 
class = "Test . ListWithChangeEvent "> 

<property name="Size" ac ce ss =" set " > 

< int >5</ int > 

</property> 

<on-event name = " Change " > 

<method-call idRef="out" name = " Pr intLn " > 

< string>event fired :-)</string> 

</ method -c all > 

</ on- event > 

</ component > 

</ component s > 

</ coml> 

Example 13] shows the structure of each CoML script: The root element coml 
contains exactly two children — meta and components. The components element 
describes the actual component composition and the meta element provides addi- 
tional platform specific information and the used version. The elements abstract 
from the target platform. It depends on the tool which processes CoML if the 
meta element is used or not. An interpreter may care about the used component 
libraries and it may define version compatiblity rules. 

The meta element describes platform specific informaiton and the compat- 
ible platform version. It consists of a list of info elements. An info element 
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describes which component library and version are used. It can contain elements 
which describe platform specific information. By separating the actual com- 
ponent composition from meta information and platform specific information 
CoML is extensible and can be adjusted to other usage scenarios and tools. 

The components element describes the actual software composition. It con- 
sists of a list of component elements. The component element declares a single 
component. It declares the component class, the used interface and the cus- 
tomization. The child elements of the component element describe the customiza- 
tion. Proper child elements are the add, the property, the method-call and the 
on-event element. However, the component element itself can be a child element 
of the add, property or method-call element. If the component element is used 
as a child element, then it describes the value or actual parameter of the enclosing 
element (like the parameter of a method call). 

Generally, the child elements are the arguments of the enclosing parent ele- 
ment. The syntax of some CoML elements is influenced by IBMs Bean Markup 
Language. 

5 Related Work 

Sun and IBM have developed their own composition language based on XML. 
However both. Sun’s JavaBean Persistence HD and IBM’s Bean Markup Lan- 
guage (BML), are tailored for JavaBeans and do not support meta information 
at all. 

The main goal of Sun’s approach is to have a proprietary standardized format 
for exchanging mainly GUI JavaBeans compositions between different Java IDEs. 
An idea similar to CoMLs primary purpose. At the beginning of the project we 
tried to use Bean Persistence. Unfortunately Bean Persistence expressiveness for 
composing components via events is too limited. Bean Persistence uses special 
proxy classes to build an event connection and does not provide XML elements 
to clearly mark an event connection. Bean Persistence depends on the JavaBean 
mechanism for detecting event sources — i.e. method naming conventions — and 
does not abstract the actual event-gluing. The original JavaBeans specification 
does not define a logical containment/hierarchy relationship among connected 
beans and Bean Persistence does not support it either. 

GoML is influenced by BML. The main differences are that GoML is not 
focused on JavaBean composition, that GoML supports interfaces where BML 
allows explicit type conversions, that GoML does not allow embedding of foreign 
scripting code — such as JavaScript — in order to remain platform independent, 
and that GoML supports meta information. 

During the last years several software composition approaches emerged. Ap- 
proaches like Generative Programming |14J which subsume besides other meth- 
ods Aspect Oriented Programming |15j , Generic Programming |16j , and Software 
Product Lines m- 

G-|— k and Ada programmers know what generics or templates (like the STL 
m) are. Some of the main research interests of generic programming are how 
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to design generic components and algorithms with the appropriate theory and 
formalism behind it, and which software technologies (like C++ templates) for 
programming generic components are usable. Very generic components are hard 
to customize and very specific components are hardly reusable, because they are 
tailored for one special purpose. 

One characteristic of the evolution to the industrial age is mass production. 
Henry Ford introduced the product line when he manufactured the Ford T Model 
for the mass. Software Product Lines try to use this paradigm for producing a 
family of software. The members of the same family have a lot of common fea- 
tures and only some variant functionality like the variations in a control software 
for a certain family of brick and mortar diesel engines. Software product lines 
cover the whole software engineering process and the necessary organizational 
changes for creating a family of software and their variants. They consider com- 
ponents as reuse in the small and product lines as reuse in the large. Some of 
the main research interests are what parts (or functionality) of a components 
interface(!) are immutable and what are variants. An academic example for a 
product line architecture is the GenVoca architecture m- 

Formal specifications and the derivative composition approach are research 
topics which evolved from the AI and knowledge based software engineering 
fields. They are subsumed under Automated Software Engineering [20| . Their 
ambitious goal is to derivate and generate the application from the specification. 

Our approach (CoPL and CoML) does not try to change the available compo- 
nents by splitting them up in a core part and a variable part, like the product line 
approach does. It tries to automate the selection of possible implementations. 
It shares the idea of automatically composition of already existing components. 
Our approach can be seen as a contribution to the approaches that share this 
vision, too. 

6 Conclusions 

An application programmer uses component plans at design-time, i.e. when he 
assemblies the components to a new application. The benefits are to have a 
script-able wizard, that produces a platform independent description of a con- 
crete component composition. 

Plans along with the CoML generator are used at a different point in time 
than scripting languages, which are typically interpreted or executed (like e.g. 
Piccola, JavaScript or IBM’s Bean Markup Language). These languages are in- 
terpreted at run-time, i.e. at the end user’s computer during actual execution of 
the application. 

The output of the generator is a composition description in CoML. CoML 
is component technology and platform independent. Different tools like devel- 
opment tools, documentation tools or software architecture visualizing tools can 
use CoML, e.g., for exchanging component compositions or displaying them in 
different manners. Of course, CoML can be interpreted as well and currently we 
have interpreters for Java and Microsoft’s .NET component platform. 
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CoPL and CoML are an ongoing research project and not finished yet. Some 
of future research efforts for CoML cover how to handle different formal param- 
eter behavior of method calls and how to provide a convenient error handling 
mechanisms. It is still not resolved which information should be part of the meta 
information and whether we will address cross platform composition as well. We 
consider to use an XML based syntax for CoPL and if the selection mechanism of 
the Decision Spot should cover semantic criteria as well. We also need to improve 
our tools (CoML generator etc.) and to integrate them in existing development 
environments. 
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Abstract. Universal graphical editor dehnition language based on logi- 
cal metamodel extended by presentation classes is proposed. Implemen- 
tation principles of this language, based on Graphical Diagramming En- 
gine are described. 



1 Introduction 

Universal programming languages currently have become more or less stable, 
the main effort in this area is oriented towards improving programming environ- 
ments and programming methodology. However, the development of specialised 
programming languages for specific areas is still going on (most frequently, this 
type of languages is no more called programming languages, but specification or 
definition languages). One of such specific areas is the definition of graphical ed- 
itors. The need for various graphical editors and similar tools based on graphical 
representation of data increases all the time, because due to increased computer 
speeds and size of monitors it is possible to build graphical representations for 
wider subject areas. In this paper the Editor Definition Language (EdDL) 
for a simple and convenient definition of wide spectrum of graphical editors is 
proposed, and the basic implementation principles of EdDL are described. 

Let us mention some earlier research in this area. Perhaps, the first similar 
approach has been by Metaedit [1], but its editor definition facilities are fairly 
limited. The most flexible definition facilities (and some time ago, also the most 
popular in practice) seem to be the Toolbuilder by Lincoln Software. Being a 
typical meta-CASE of early nineties, the approach is based on ER model for 
describing the repository contents and special extensions to ER notation for 
defining derived data objects which are in one-to-one relation to objects in a 
graphical diagram. The diagram itself is being defined by means of a frame 
describing graphical objects in it and the supported operations. A more academic 
approach is that proposed by Kogge [2], with a very flexible, but very complicated 
and mainly procedural editor definition language. Another similar approaches 
are proposed by DOME [8] and Moses [9] projects, with fairly limited definition 
languages. Several commercial modelling tools (STP by Aonix, ARIS by IDS 
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prof. Scheer etc) use a similar approach internally, for easy customisation of 
their products, but their definition languages have never been made explicit. 

Our approach in a sense is a further development of the above-mentioned 
approaches. We develop the customisation language into a relatively independent 
editor definition language (EdDL), which, on the other hand, is sufficiently rich 
and easy to use, and, on the other hand, is sufficiently easy to understand. 
At the same time it can be implemented efficiently, by means of the universal 
Editor Engine. Partly the described approach has been developed within the EU 
ESPRIT project ADDE [3], see [4] for a preliminary report. 

2 Editor Definition Langnage. Basic Ideas 

The proposed editor definition language consists of two parts: 

— the language for defining the logical structure of objects which are to be 
represented graphically 

— the language for defining the concrete graphical representation of the selected 
logical structure. 




Fig. 1. Logical metamodel example 



The separation of these two parts is the basis of our approach. For describing 
the logical structure there exists a generally adapted notation — by UML class 
diagrams [5], which typically is called the logical metamodel in this context. 
Fig.l shows a simple example of a logical metamodel for business activities. 
Business activities are assumed to be parts of a larger process. There may be 
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a dependency between business activities (this dependency may be a message 
passed from one activity to another, but also something more general). An ac- 
tivity may be triggered by an (external) business event. Business activity may 
have a performer — a position within a company. This example will be used in 
the paper to demonstrate the editor definition features. Fig.l needs one tech- 
nical remark to be given. Attributes of a class there are extracted as separate 
classes, linked via an association with the predefined role name has attribute to 
the parent class. This attribute extraction is technically convenient for defining 
the presentation language part. Otherwise the logical metamodel is an arbitrary 
UML class diagram. 




Fig. 2. Example of instance diagram 



Fig. 2 shows an example of an instance diagram (object diagram in UML 
terms) corresponding to the logical metamodel in Fig.l. Our goal is to define 
the corresponding editor, which in this case could be able to present the instance 
diagram as a highly readable graphical diagram in Fig. 3 (where the traditional 
rendering of dependencies by oriented lines is used). A special remark should 
be given with respect to Position. It is not explicitly represented in diagram in 
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Fig. 3, but double- clicking on the performer name is assumed to navigate to 
(i.e. to open) a special editor showing the relevant position (this other editor is 
not specified here). The navigation and the prompting (the related action by 
means of which such a reference can be easily defined) are integral parts of our 
editor definition facilities. 



Application for rental 



^ j/ ^eceive custome ^ 



-^l^^efine requiremer^ 



Assess credit 



Performer = Rental clerk 



Fig. 3. Business activity diagram example 



Roughly speaking, the goal of our definition language is to describe the trans- 
lation of pictures like Fig. 2 into equivalent pictures like Fig. 3. So it is a sort of 
graphics translation language. 

Now let us start a detailed outline of the EdDL. Like any real language, it con- 
tains a lot of details, therefore we will concentrate only on the basic constructs. 
The language will be presented as an extension of the logical metamodel adher- 
ing to the UML class diagram notation. Fig. 4 demonstrates the use of EdDL 
for the definition of the example editor (with some minor details omitted). In 
this figure rectangles represent the same classes from the logical metamodel in 
Fig. 1, but rounded rectangles represent classes being the proper elements of 
EdDL. Classes with class names in bold represent abstract classes, which cannot 
be modified (they are used mainly for inheritance) . Similarly, bold role names of 
associations represent the fixed ones. We remind that the underlined attributes 
(to be seen in EdDL classes) are class attributes (the same for all instances) 
according to UML notation. 

The first element added to the logical metamodel is the diagram class {Busi- 
ness activity diagram), together with standard associations (with the role name 
contains) to the contained diagram objects, and as a subclass of the fixed 
Diagram class. One more standard association for diagram is the refinement as- 
sociation (refines), which defines that a Business Activity can be further refined 
by its own Business activity diagram (this definition is sufficient for the Editor 
Engine to enable this service). 

Each of the metamodel classes, which must appear as graphical objects in 
the diagram, are linked by an unnamed association to its presentation class — 
a subclass of standard classes box or line. The presentation class may contain 
several class attributes (with predefined names). Thus the presentation class for 
Business Activity — the Activity box class says that every business activity must 
be represented by a rounded rectangle in a light blue default colour. The Icon 
representing this graphical symbol on the editor’s symbol palette (to create 
a new business activity in a diagram) is also shown. For presentation classes 
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being lines the situation is similar, but there may be lines corresponding to 
associations in the metamodel {Triggering line) or to classes {Dependency line). 
The latter case is mostly used for lines having associated texts in the diagram 
(corresponding to attributes of the class; here the Message name). For showing 
the direction of line (and other similar features) the relevant role names from 
the metamodel are referenced in the presentation class (e.g. start— predecessor) . 

Class attributes are being made visible in diagrams by means of a com- 
partment presentation class. The most important attribute of a compartment 
class is the position — for boxes in the simplest case it means the number of 
the horizontal slice of the box, for lines it means the relative positioning (start, 
middle, end). Compartment class may contain also style attributes (visible tag, 
separator, font, etc.). 



I^om^rtmen^ 




Position name 


nerfnrmer 


0..1 






value 




Position 





1 









Fig. 4. Business activity diagram editor definition in EdDL 
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The most interesting element in this EdDL example is the definition of 
prompting and navigation. They are both related to the situation when an 
attribute (i.e. its value) of a metamodel class (the Performer for Business ac- 
tivity in the example) actually is determined by an association of this class (a 
derived attribute in UML terms). Here the Performer value actually must be 
equal to the Position name of that Position instance (if any) which is linked 
by the association having the role name Performed by (the fact that a Position 
must be represented by its Position name is defined by the display association) . 
Prompting here means the traditional service found in an editor that a value can 
be selected from the offered list of values (value of Performer selected from the 
list of available Position names), with the automatic generation of the relevant 
association instance as a side effect. The navigation means the editor feature that 
double-clicking on the Performer field (which presents the Performer attribute) 
in a Business activity box automatically invokes some default editor for the Posi- 
tion (the target of the association) . Both Prompting and Navigation are shown in 
the EdDL as fixed classes linking the attribute to the relevant association (they 
may have also their own attributes specifying, e.g. the prompting constraints). 
Note that Position has no presentation class in the example, consequently its 
instances are not explicitly visible in the Business activity diagram. 

Certainly EdDL contains more features than demonstrated in Fig.4, e.g. var- 
ious uniqueness constraints, definitions for attribute “denormalisation”, modes 
of model/diagram consolidation etc. The EdDL coding shown in Fig. 4 was sim- 
plified to make it more readable. The actual coding used for the commercial 
version of EdDL is much more compact, here the metamodel class attributes 
are defined in the traditional way, and most of Presentation classes are coded 
just as UML constraints (properties) inside a metamodel class. Nevertheless the 
semantics of this language is just the one briefly described in the paper. We 
assert that EdDL is expressive enough to define practically any types of editor 
that could be used to build related sets of diagrams in system modelling area. 
Namely the inter-diagram relations such as prompting and navigation are the 
most complicated ones, and they successfully managed in EdDL. Finally, Fig. 5 
shows the defined editor in action. 



3 EdDL Implementation Principles 

EdDL has been implemented by means of an interpreter which in this case is 
named Editor Engine. When an editor has been defined in EdDL the Editor 
Engine acts as the desired graphical editor for the end user. Here only the main 
principles of implementation will be discussed. The first issue is the information 
storage. It is universally accepted nowadays that the logical metamodel describes 
directly (or very close to it) the physical structure of the tool repository. This 
repository can be an OODB, a special tool repository (e.g. Enabler [6]) or a 
relational DB. This is one more argument why the editor definition should be 
based on a separately defined metamodel. 
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Fig. 5. Editor in action 



Fig. 6 shows the general architecture of the EdDL approach. A key aspect is 
that Editor Engine (EE) relies on Graphical Diagramming Engine (GDE) 
for all diagram drawing related activities. The primitives implemented by GDE 
— diagram, box, line, compartment etc. and the supported operations on them 
are very fit for this framework. 



Editor 

Definition 



Modeling 

tool 




} For every 
diagram 
type 



Fig. 6. Architecture of EdDL implementation 



Thus the interface between EE and GDE is based on very appropriate high 
level building blocks, there is no need for low level graphical operations in EE 
at all. The GDE itself was developed by IMGS UL initially within the frame- 
work of ADDE project, with a commercial version later on. It is based on very 
sophisticated graph drawing algorithms [7]. 

The general technology of using EdDL for defining a set of editors is quite 
simple. For each of the editors its definition on the basis of the relevant meta- 
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model fragment is built. Then these definitions are parsed and assembled into 
one set. EE “performs” this set, behaving as a modelling tool containing the 
defined set of diagrams. A lot of tool functionality — “small operations” such as 
copy-paste and “large operations” such as load and save are implemented in EE 
in a standard way and need no special definitions. Certainly, external modules 
can be included for some specific operations. 

The practical experiments on using EdDL and EE have confirmed the ef- 
ficiency and flexibility of approach. The defined editors (like the one in Fig. 5) 
behave as industrial quality graphical editors. The flexibility has been tested by 
implementing full UML 1.3 and various specific business process related exten- 
sions to it. 

4 Conclusions 

The paper presents a brief outline of the graphical editor definition language 
EdDL and its implementation. But we can view all this also from a different 
angle. Actually a new kind of metamodel concept application for a specific area 
— editor definition — has been proposed. However this approach can be signif- 
icantly more universal, since it is generally accepted that object model (Class 
diagram) is a universal means for describing the logical structure of nearly any 
system. Thus the same approach of extending this model by special “presenta- 
tion” classes could be used, e.g. to define model dynamics, simulation etc., but 
this is out of scope for this paper. 
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Abstract. In the report the programming languages Oberon-2 is dis- 
cussed from the point of view of convenience to program the discrete 
event simulation systems (DESS). Its predecessor Modula-2 was used as 
the basic language for a number of simulation packages and was proved 
to be good for it, but has Oberon-2 enough features to replace it and 
stand against domination of C++ in this special area? Are there com- 
pilers and programming environments good enough for this purpose? Is 
it possible to use existent libraries and transfer software between differ- 
ent platforms? These and other questions are discussed on the examples 
of ObSim-2 simulation package and XDS Modula-2&Oberon-2 program- 
ming system. 



1 Introduction 

The programming language Modula-2 for a long time has attracted attention of 
the developers of DESS. It was proved to be a convenient tool for the develop- 
ment of well-structured programs with the possibility of organization of quasi- 
parallel processes. The later is of a special importance for Simula-like DESS. 
A number of simulation packages on Modula-2 were designed m-m- Moreover, 
Modula-2 was proved to be so good programming language for simulation pack- 
ages that it was used as a basis for the design of special simulation languages. 
For example, one the most powerful simulation systems of the late, MODSIM 
III [T2], has Modula-like language. 

One of the authors designed the package SIDM-2 [S] using Modula-2 as the 
basic language. 

Other author is one of the designers of the XDS Modula-2 and Oberon-2 
programming system. The XDS Modula-2 and Oberon-2 programming system 
allows, at first, to use the object-oriented resources of the second language, and 
secondly to transfer to the new operational environment earlier programmed 
non-object-oriented part of the package SIDM-2. Doing it is possible completely 
to adhere to the standard ISO, that makes possible the creation of the really 
portable simulation package. This new package ObSim-2 includes some modules 
on the language Modula-2, providing generation of the pseudo-random values 
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and processes, matrix calculations and data processing. The Oberon-2 modules 
are intended for the description of frame and behavior of simulated systems. 
The compatibility of XDS multi-language programming system with main C-|— I- 
compilers allows using a number of useful libraries also. 



2 Advantages and Shortcomings of Modula-2 as 
Programming Language for DESS 

In Modula-2 was discussed as a basic language for the DESS design. It is well 
known [2] that any simulation language ought to provide the following features: 

-- means for the data organizing that provide simple and effective simulation; 

— convenient means for the formulation and running the dynamic properties 
of a simulated system; 

— possibility to simulate stochastic systems, i.e. procedures for generating and 
analysis of random variables and time series. 

Now we can add that the object orientation is also of prime importance. 
Really, it could be said that OOP originated from simulation (refer to Simula- 
67! 0). 

It is clear to see that Modula-2 satisfies all demands but one: it has no 
standard modules for statistical support of a simulation process (no pseudo- 
random generators and data processing), but this is not a serious shortcoming 
as it is not very hard to design a special module with appropriate procedures. As 
for object-oriented properties, Modula-2 is an intermediate language. Modular 
concepts of this language allow to interpret some object-oriented features. Some 
extensions (TopSpeed for example []) include real class specifications. Moreover, 
Modula-2 has such valuable feature as quasi-parallel programming, that makes 
possible (with restrictions) process-oriented simulation. That explains why it was 
popular for DESS design in the late 1980s and early 1990s. Simulation package 
SIDM-2 also was programmed on Modula-2 because of its good convenience for 
the purpose. 

This package provides the description of systems in the terms of discrete 
interactive processes (as in Simula) and events (similar to Simscript). This ex- 
perience proves that Modula-2 is good for the purpose, but the TopSpeed ex- 
tensions, first of all the object-oriented extension (classes) of the language were 
essentially used for rises of the efficiency of programs. The last circumstance 
has made the package hardly portable. At the same time SIDM-2 clearly shows 
that object-oriented features are of the prime importance for the efficiency and 
usability of simulation tools. 

Processes are the part of Modula-2 that makes it good for the design of 
process-oriented DESS (Simula-like), but the process concept in Modula-2 has 
one severe shortcoming: it is simple to create any number of processes dynam- 
ically, but it is impossible to remove one from the program. According to the 
language description end of any process is the and of a whole program. 



540 A.S. Rodionov and D.V. Leskov 

Strict typing is one of the main advantages of Modula-2. It allows a lot 
of possible mistakes to be avoided on the early stages of the program model 
development. At the same time general pointer (type ADDRESS) allows to create 
indirect transition of parameters to event procedures and processes. Using that 
is dangerous but effective. Thus, in SIDM-2 event procedures have the following 
type: 

TYPE EVENT_PR0C = PROCEDURE (ParField : ADDRESS); 

When one ties event with procedure he use the special procedure 
Event" . SetProc while to designate the parameters one ought to create an exam- 
ple of structure designed for this special kind of event and then ties it with event 
procedure using another special procedure Event" . SetPars. Let us to illustrate 
this by the following example. 

TYPE EVENT_PARS_POINTER = POINTER TO EVENT_PARS; 

EVENT_PARS = RECORD 

Num_of _Device : CARDINAL; 

Cust : POINTER TO Customer; 

END; (* EVENT_PARS *) 

PoinEvent = POINTER TO EVENT; 

VAR ArrPars : EVENT_PARS_POINTER; 

Arrival : PoinEvent; 



CLASS Event (Link); 

Pars : EVENT_PARS_P0 INTER; 
Proc : EVENT_PR0C; 



PROCEDURE SetPars (Pars : ADDRESS); 
PROCEDURE SetProc (Proc : EVENT_PR0C) ; 



END Event ; 



PROCEDURE New_ArrivaI(Pars : EVENT_PARS_POINTER) ; BEGIN 
UpdateStat (Device [Pars" . Num_of _Device] ) ; 



END New_ArrivaI ; 



NEW(Arrival) ; Arrival" . SetProc (New_ArrivaI) ; 



NEW (ArrPars) ; 

ArrPars" .Num_of _Device : =k; 

ArrPars" . Cust : =CurrentCust ; Arrival" . SetPars (ArrPars) ; 
Arrival" . Schedule (Time ()+Negexp(l . 0) ,TRUE) ; 



In this example the fragment of event procedure New_ArrivaI is presented 
that needs some parameters for execution. Special object Arrival of the class 
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Event is used for scheduling the event. It is clear to see that the procedural 
type EVENT _PRDC allows to transfer parameters quit naturally. Unfortunately, as 
it was stated above, it is dangerous as it is not protected from any mistake in 
the type matching. 



3 Modula-Like Simulation Systems 

Some DESS have their own Modula-like programming languages. Most famous 
from them is MODSIM III [T^]. The very fact of usage Modula-2 as a frame for 
the design of simulation languages proves its good features for the purpose. It 
is interesting that object-oriented means in MODSIM III are similar to those in 
the TopSpeed object-oriented extension of Modula-2 but are more powerful (for 
example it is possible to use multiple inheritance). 

As in Modula-2 in MODSIM III definition and implementation modules are 
used. From m we can take the following example of the library module called 
TextLib: 

DEFINITION MODULE TextLib; 

PROCEDURE Reverse (INOUT str : STRING); 

END MODULE. 

IMPLEMENTATION MODULE TextLib; 

PROCEDURE Reverse (INOUT str : STRING); 

VAR { REVERSES THE INPUT STRING } 

k : INTEGER; 

tempStr : STRING; 

BEGIN 

FOR k := STRLEN(str) DOWNTO 1 

tempStr := tempStr + SUBSTR(k, k, str); 

END FOR; 
str :=tempStr; 

END PROCEDURE; { Reverse } 

END MODULE. 

For the dynamic objects MODSIM III has operator NEW for creation and 
DISPOSE for destroying. That allows having an arbitrary number of dynamic 
objects during simulation run. 

Of course, there are developed means for the event control and statistical 
support of a simulation process. 



4 Can Oberon-2 Substitute Modula-2 in Simulation? 

As it is well known, main differences between Oberon-2 and Modula-2 lay in 
object-oriented means [HUII4j . 
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We do not know about if Nicolas Wirth was acquainted with MODSIM III 
when he designed Oberon-2, but it is true that most of object-oriented means 
that were realized in MODSIM III are also presented in Oberon-2. Among them 
are: 

1. multiple inheritance; 

2. overriding methods; 

3. concurrency. 

Of most importance for the Simula-like simulation is the possibility to stop 
process (co-routine) without ending the whole program. 

It is true, however, that some new (in comparison with Modula-2) features of 
Oberon-2 have hardened the programming of simulation models. Among these 
features is removing of the ADDRESS type from the language that makes im- 
possible to use the approach to the parameters transition described above. 

Simulation package ObSim-2 is the successor of SIDM-2. This package, as well 
as SIDM-2 [H], first of all is intended for simulation of systems, representable as 
a collection of inter-reacting discrete processes (like in Simula-67). At the same 
time the event-driven simulation means are included in this package. 

It is possible to say, that the systems are considered that are representable 
as a collection of objects exchanging handle and information. The object is char- 
acterized by: 

— data structure; 

— rule of operations; 

— operating schedule. 

The data structure of the object includes its own data and the auxiliary 
information. This auxiliary information includes: 

Number - individual number (usually is used for debugging); 

Terminated - tag of a completeness of the process; 

Name - a name of the object (important for the tracing mode); 

TimeMark - the moment of creation; 

EvNote ~ the reference to the event notice that is bounded with the object; 
Proc - the reference to a co-routine implementing the operation rule of the 

object. 

The operation rule of the object is represented by the quasi-parallel process 
that is realized or with the help of the Oberon-2 process (co-routine) or as the 
sequence of procedures (methods) of the object calls. 

Under the operating schedule of the object an algorithm of choice the se- 
quences of active phases of its operation in time is understood. The control 
transferring between objects is admitted only via a means of events planning. 

According to mentioned above the following resources are included in the 
package: 
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— objects description; 

— events planning; 

— interaction of objects and storage of their data; 

— the base means of statistical support of simulation experiment. 

The special type of an event notice is used to provide the alternative (active 
phase of a process or procedure) mode of an event processing: 

TYPE EventNotice*=RECDRD(SS .Link) ; 

EvTime- : LONGREAL; (* plcuined event time *) 

Host- : PoinEntObj ; (* if process *) 

END ; — EventNotice 

Here the SS . Link is the class of links intended for placement into the event 
control list. The type PoinEntObj is of the special interest here: 

TYPE 

PoinEntObj* = POINTER TO EntOrObject; 

PoinObj* = POINTER TO Object; 

PoinEv* = POINTER TO Event; 

TYPE EntOrObject*=RECORD(SS .Link) ; 

_Name- : ARRAY 16 OF CHAR; (* for debugging *) 

No- : LONGINT; (* number, for debugging *) 

EvNotice- : PoinEvNote; 

END; — EntOrObject 

TYPE Object*=RECORD(EntOrObject) ; 



TYPE Event*=RECORD(EntOrObject) ; 



The event control procedure, based on the current type of PoinEntObj makes 
decision about to transfer the control to a process bounded with an object or 
call an event processing procedure. 

5 Can Oberon-2 Win Competitive Struggle with C-| — h? 

It is a completed fact that C-l— I- is now the main program development tool in 
a whole and in DESS design in particular. There are some reasons for this: 

1. good object-oriented tools; 

2. powerful compilers; 

3. modern environments; 

4. good acknowledged standard that allows to transfer programs between dif- 
ferent platforms; 

5. availability of a lot of different libraries for numerical analysis and computer 
graphics. 
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There is also one more subjective reason: somehow programming on C++ 
became “good fashion” among young programmers, may be because C is the 
main programming language in UNIX and to work under UNIX means to work 
in network environment that is prestigious also. Moreover, it is possible to say 
that there is some snobbery in membership of “C-programmers club” . 

By no we means do not deny good properties and efficiency of C and C++ 
in system development. At the same time we are aware of some their shortcom- 
ings. As hardest of them we can mention freedom of type conversion and weak 
protection from data access violation. C++ programs are not as easily readable 
as it is wanted also. 

Oberon-2 as successor of Pascal can replace it in education (Pascal is still one 
of widely used programming languages in education) but it has some features 
suitable for the large program system design also. Really the only reason why it 
is not widely used is absence of the brand compiler on world market. Available 
compilers are mostly developed by universities and so have no good support and 
additional libraries. 

6 XDS Modula-2 and Oberon-2 Programming System 

The XDS Modula-2 and Oberon-2 programming system is a multi-language pro- 
gramming environment that allows to use native and second-part C programs 
also. This system includes ANSI Modula-2 and Oberon-2 compilers and a num- 
ber of libraries that allows to control co-routine programming that is of a prime 
importance in simulation. 

The possibility of using second-parties C-libraries in the XDS system allows 
to utilize the widely spread systems for the interface creation, that is very im- 
portant for programming of modern DESS systems. 

The first version of the package ObSim-2 was already used for simulation of 
digital networks with circuit switching that has shown greater convenience to 
the description of the simulated system also, than earlier used package SIDM-2. 
It is due to the object-oriented features of Oberon-2 mainly. 
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